I must admit that I haven't followed all the discussion of the
curl_off_t/LFS work for 7.19.0; I figured as long as the result was a
working library with LFS capabilities I'd be happy. Unfortunately I seem
to have run into a problem with the new infrastructure.

The problem is most acute on Solaris. Solaris has both 32-bit and 64-bit
environments on the same machine. Therefore, I've always built both 32-
and 64-bit versions of my application, which in turn means having 32-
and 64-bit versions of libcurl.

After the upgrade to 7.19.0, the 32-bit build worked fine but the 64
failed with a message

        cur/curlrules.h:134: error: size of array __curl_rule_01__ is negative

This appears to be because the new design depends on the installation of
a header "curlbuild.h" with the unitary definition:

        #define CURL_SIZEOF_LONG 4

Clearly, it's impossible for this to be true for both the 32- and 64-bit
environments at the same time. With the following manual modification:

        #ifdef __arch64__
        #define CURL_SIZEOF_LONG 8
        #else
        #define CURL_SIZEOF_LONG 4
        #endif

I can build, but this is presumably some combination of Solaris-,
Sparc-, and gcc-specific.

More generally, this bothers me because it seems to violate a norm.
Since our application uses a large number of libraries on a large number
of platforms, our practice has been to keep only a single set of header
files while building out the binary libraries per platform. Thus we have
N copies of libcurl.so for N platforms but only a single copy of curl/*.h.

With the addition of curlbuild.h and curlrules.h, the curl/*.h files now
document not only an API but also the details of how libcurl was built
on one particular system. This means we must keep a copy of curl/*.h for
every compilation environment, which seems to me a significant step
backward in both elegance and utility.

Thoughts?
MB
Received on 2008-09-04