On Thu, 4 Sep 2008, Mohun Biswas wrote:

> 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.

If only the world was that simple. Clearly you weren't happy with _only_ this,
as apart from the bug you mention this is what you got... ;-)

> 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

Not exactly. On Solaris you run ./configure and that is then supposed to
replace your include/curl/curlbuild.h file with one where these variables have
been set to the sizes and types configure found.

Doesn't this work for you? Or did you run configure for the 32bit case and
then built for the 64bit case without rerunning configure?

> 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.

Well yes now you need to build and install both the lib and the associated
headers in its own prefixes:

  ./configure --prefix=/lib/for/one-build --options-for-one
  make
  make install

  make clean
  ./configure --prefix=/lib/for/second-build --options-for-second
  make
  make install

I do see how this is not properly document atm, but apart from the surprise
you get and the fact that you need to get used to this idea, I don't think
there a lot of harm in this. Previously, we had a situation where it was very
easy to make mistakes since the headers and libraries required the app to know
about things that the current approach tries to take care and inform about in
its public headers.

Or does it harm your use and your application any more than what I've tried to
sum up?

-- 
  / daniel.haxx.se