Brian Gough bjg@gnu.org writes:
Nettle should work better with other GNU packages if it follows the GNU standards, as the assumption of lib/ as a default is a common one in other configure scripts.
I don't change the default lightly, but I still think it's the right thing to do when
1. The user has not provided --libdir explicitly.
2. One is building on a multi-abi system, which is a case where the autoconf default doesn't even try to do the right thing.
3. The autoconf default is known to be wrong.
For comparison the GMP library has ABI detection via configure but keeps the library directory as lib/ by default.
I'm reasonably familiar with the gmp configure script. It's true that it currently always uses lib/ as the default, regardless of ABI, but it's ABI related hacks can also cause other nasty surprises. So it's a good example to exhibit the complexity of the problem, but it's not currently solving it.
As for linux on x86_64, it appears that debian (and derivatives, I imagine) put 64-bit libraries in lib/, while the distributions with roots in redhat (at least rhel 5 and fedora 14) and gentoo follow the fhs conventions and put 32-bit libraries in lib/. So to do the right thing, configure has to distinguish between these two cases. What a mess (but just the type of mess configure.ac is intended to help sort out).
Regards, /Niels
On Thu, Apr 14, 2011 at 10:25 AM, Niels Möller nisse@lysator.liu.se wrote:
Nettle should work better with other GNU packages if it follows the GNU standards, as the assumption of lib/ as a default is a common one in other configure scripts.
I don't change the default lightly, but I still think it's the right thing to do when
- The user has not provided --libdir explicitly.
- One is building on a multi-abi system, which is a case where the
autoconf default doesn't even try to do the right thing. 3. The autoconf default is known to be wrong.
I don't really find this a serious problem because libdir can be provided by the one performing compilation and fix any issues, anyway.
As a matter of policy though, I think the FHS way of storing in /usr/lib 32-bit binaries, even if the default system compiler outputs 64-bit binaries, is quite absurd, and looks like a relic from the era that binary only programs came with 32-bit intel code only. Systems like debian correctly for me do not follow this approach because it has no benefit for the user of a multi-lib system and only causes confusion, as programs in /usr/bin do not use libraries in /usr/lib. What you call a multi-lib system is actually a system with a native word size and a compatibility mode with another (smaller) word size. Why one not using the compatibility mode have an empty /usr/lib? This requirement is intended only for the one distributing ancient 32-bit binaries and I see no compelling reason for free software or open systems to follow that by default.
regards, Nikos
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se