Brian Gough | 31 Mar 00:48 2011
Picon

different lib directories for gnutls and nettle

Hi, now that GNU TLS is using nettle I notice there is a difference
between the --libdir for the two packages on 64 bit.

Nettle installs to $prefix/lib64/ and GNU TLS looks for it in
$prefix/lib/ -- so it fails and the standard configure/install to a
prefix doesn't work.

  (cd nettle-2.1 ; ./configure --prefix=/foo ; make ; make install)
  (cd gnutls-2.12.0 ; ./configure --prefix=/foo ; make ; make install)

  checking whether to use nettle... yes
  checking for libnettle... no
  configure: error: 
    ***
    *** Libnettle 2.1 was not found.

  make: *** [configure-work/gnutls-2.12.0/configure] Error 1

See http://chapters.gnu.org/~bjg/gsrc/logs/gnutls.txt for a complete
example.
Nikos Mavrogiannopoulos | 3 Apr 01:42 2011

Re: different lib directories for gnutls and nettle

On 03/31/2011 12:48 AM, Brian Gough wrote:
> Hi, now that GNU TLS is using nettle I notice there is a difference
> between the --libdir for the two packages on 64 bit.
> Nettle installs to $prefix/lib64/ and GNU TLS looks for it in
> $prefix/lib/ -- so it fails and the standard configure/install to a
> prefix doesn't work.

Indeed it seems nettle for some reason uses the /usr/lib64. Niels,
is there really a reason for that? As I understand from the FHS[0]
/usr/lib is the system library directory. /usr/lib64 and /usr/lib32
might not even be there.

regards,
Nikos

[0].
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
Niels Möller | 12 Apr 11:27 2011
Picon
Picon
Picon

Re: different lib directories for gnutls and nettle

Nikos Mavrogiannopoulos <nmav@...> writes:

> Indeed it seems nettle for some reason uses the /usr/lib64. Niels,
> is there really a reason for that? As I understand from the FHS[0]
> /usr/lib is the system library directory. /usr/lib64 and /usr/lib32
> might not even be there.

Sorry for the late reply. A bit down in the same document,
http://www.pathname.com/fhs/pub/fhs-2.3.html, it says

  /lib64 and /lib32 : 64/32-bit libraries (architecture dependent)

  The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place
  64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in
  /lib.

If you believe this, then it's wrong to install 64-bit libraries in lib.
And I believed so when I wrote this part of the nettle configure.ac...

But then it turned out that at least debian on x86_64 ignores this part
of the FHS, and puts the 64-bit libraries in lib, and 32-bit libraries
in lib32. Which seems to also be the freebsd way of doing it.

In the debian case, lib64 is a symlink to lib, so it doesn't matter for
a 64-bit builds (they will be installed in lib64, which is a symlink to
lib, which is tye right place), while a build with ./configure CC="gcc
-m32" && make && make install will install the 32-bit library files in
the wrong place.

I'm not sure what the right thing is. Is there any distribution which
(Continue reading)

Brian Gough | 12 Apr 15:31 2011
Picon

Re: different lib directories for gnutls and nettle

At Tue, 12 Apr 2011 11:27:42 +0200,
Niels Möller wrote:
> I'm not sure what the right thing is. Is there any distribution which
> actuallly does what the FHS says? If so, I guess configure needs to
> check what directories exists, and install in lib$ABI whenever that
> directory exists, otherwise in lib. I haven't got around to fixing that.

Hi Niels. 

I don't know what is the correct interpretation of the FHS, but by
default all other autoconf'ed and GNU packages always use
libdir=$prefix/lib (with the --libdir option allowing it to be
overridden if someone wants to use lib64 or whatever).

So I'd recommend to use the autoconf default of $prefix/lib, as you
will be in the good company of hundreds of other packages that way.

The distributions already have their own ways of using --libdir on
autoconf'ed packages so you don't need to worry about it yourself.

--

-- 
Brian Gough

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel
Niels Möller | 12 Apr 16:48 2011
Picon
Picon
Picon

Re: different lib directories for gnutls and nettle

Brian Gough <bjg@...> writes:

> I don't know what is the correct interpretation of the FHS, but by
> default all other autoconf'ed and GNU packages always use
> libdir=$prefix/lib (with the --libdir option allowing it to be
> overridden if someone wants to use lib64 or whatever).

And the default is broken for multi-abi systems, since it means that a
plain ./configure && make && make install may well overwrite a working
library in /usr/local/lib with a library for a different ABI. With
autoconf defaults, this will happen, e.g., if you compile on Solaris (or
on some gnu/linux siystem which actually obeys the FHS), using a
compiler which by default generates 64-bit code).

Now, most packages are not aware of what ABI they are being compiled
for, but nettle is. It has to figure it out, in order to select the
right assembly files.

> The distributions already have their own ways of using --libdir on
> autoconf'ed packages so you don't need to worry about it yourself.

I don't worry so much for distributors. To use a sane libdir default is
intended to help people who compile nettle from source themselves,
rather than installing their distribution's nettle package.

I'd be happy to have autoconf solve this problem for me, but currently
it doesn't. Library installation is a bit complex, with various
workarounds. Another issue not currently solved by autoconf (nor by
nettle's build system) is w*ndows dlls, which should usually be
installed in bin rather than lib. I've heard that automake (or maybe it
(Continue reading)

Brian Gough | 14 Apr 02:36 2011
Picon

Re: different lib directories for gnutls and nettle

At Tue, 12 Apr 2011 16:48:21 +0200,
Niels Möller wrote:
> 
> Finally: If the current hack doesn't work, I'd appreciate a complete bug
> report. What system is it? Which library directories exists (incluing
> symlinks)? Which directory is expected to hold libraries for which ABI?

Not actually a bug as such, but differing standards.  The GNU Coding
Standards specify lib/ as the default library install directory on any
system.  The FHS and GNU Coding Standards are different on this point.

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.  

For comparison the GMP library has ABI detection via configure but
keeps the library directory as lib/ by default.

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel
Niels Möller | 14 Apr 10:25 2011
Picon
Picon
Picon

Re: different lib directories for gnutls and nettle

Brian Gough <bjg@...> 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
(Continue reading)

Nikos Mavrogiannopoulos | 14 Apr 10:55 2011

Re: different lib directories for gnutls and nettle

On Thu, Apr 14, 2011 at 10:25 AM, Niels Möller <nisse <at> 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
> 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.

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.

(Continue reading)

Tomas Mraz | 14 Apr 11:05 2011
Picon

Re: different lib directories for gnutls and nettle

On Thu, 2011-04-14 at 10:55 +0200, Nikos Mavrogiannopoulos wrote: 
> On Thu, Apr 14, 2011 at 10:25 AM, Niels Möller <nisse <at> 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
> > 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.
> 
> 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.
(Continue reading)


Gmane