On Sat, 6 Sep 2008, Mohun Biswas wrote:

> This can be seen by the fact that though splits like /usr/lib and
> /usr/lib/64 are ubiquitous in 64-bit systems, there's no such thing as
> /usr/include/64. So in this sense curl really is departing from
> long-established norms and makes me wonder "what makes curl different from
> all other software"?

Well, this may sound a bit harsh and blunt but:

We've fought this issue for a long time and NOBODY has presented even a
half-baked solution for libcurl that fixes some of the problems we've had,
without generating system-specific headers. This actually goes further than
the curl_off_t problem as we can make more portable headers (== that works
easier on more platform) now thanks to the fact that we can adapt to how the
specific systen it is installed on works.

I'm not aware of any solutions that offer 32/64-bit builds that are portable
to the extent libcurl is. Most of the 32/64-bit libs are system libs and of
course they can then easily just make the differences noticed in the headers
since they control exactly what they ship there.

Other solutions involve more tricky naming stunts such as glibc making stat()
become stat64(), but I believe that too works easier when you have more
limited target platforms and compiler variety. And as we've seen in the past,
having things differ depending on what compiler defines the app users happen
to remember can be tricky.

I don't think anyone of us would reject a solution that makes us work better
without generating system-specific headers, but for that to happen it doesn't
help one bit to question the current approach. What helps is bright and good
ideas on how the problems can be solved in other ways.

So I'm not closing any doors to future changes. But I also don't consider the
current version to be that bad, as it only takes a little documentation and it
should be easy to adapt to even if you previously didn't have to have things
setup like this.

No, curl is not different than "all other software". What do you propose we
do?

-- 
  / daniel.haxx.se