On Sat, 2008-09-06 at 10:07 -0400, Mohun Biswas wrote:
> I think it's worth emphasizing a point originally made by Tor Arntsen
> elsewhere in this thread: system vendors have _not_ gone with the
> separate-headers strategy and have been able to make it work. 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"?

For what it's worth, the way GLib solves this problem is to install the
ABI-dependent file as ${libdir}/glib-2.0/glibconfig.h, and to arrange
for pkg-config to add -I${libdir}/glib-2.0 to the CFLAGS. So, in your
situation, you would end up with /usr/lib/glib-2.0/glibconfig.h being
the 32-bit version, and /usr/lib64/glib-2.0/glibconfig.h being the
64-bit version, allowing the headers in /usr/include to remain agnostic.

I guess something like this would work for libcurl, though it will cause
a minor headache for anybody who doesn't use pkg-config. I'm not sure
how much of a concern that would be.

p.
Received on 2008-09-06