[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’
From: |
Ludovic Courtès |
Subject: |
Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’ |
Date: |
Wed, 20 Oct 2010 01:02:16 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Hi Bruno,
(Reviving a year-old thread...)
Bruno Haible <address@hidden> writes:
>
>> When passed ‘--with-PACKAGE-prefix=/p’, ‘AC_LIB_LINKFLAGS_BODY’
>> deduces ‘additional_libdir=/p/lib64’ on x86_64.
>
> Yes, this is expected on the common bi-arch Linux systems.
>
>> This doesn’t work on NixOS which doesn’t (quite) support multilib, and
>> where libs are to be found under ‘/p/lib’. Unfortunately, this leads
>> ‘AC_LIB_LINKFLAGS_BODY’ to ignore the ‘/p’ prefix altogether, both for
>> includes and libs (it ends up in the “Didn't find the library” case).
>>
>> A simple fix would be to add a ‘--with-PACKAGE-lib’ (and optionally
>> ‘--with-PACKAGE-include’) option.
[...]
> The real problem is that on a system
> where gcc knows to find 64-bit libraries under /usr/lib64, NixOS will -
> according to what you say - use a different naming convention than what
> the rest of the system does. User confusion is guaranteed.
Problem is: ‘AC_LIB_PREPARE_MULTILIB’ determines ‘acl_libdirstem’ based
on whether the library search path, as shown by ‘gcc -print-search-dirs’,
contains at least one ‘lib64’ directory.
However, GCC built with --disable-multilib on x86_64-linux-gnu installs
support libraries (libssp, libmudflap, etc.) under $prefix/lib64, not
$prefix/lib. Thus, the library search path contains at least one
‘lib64’ directory, even though the system is not multilib-capable.
It’s not clear to me whether the choice of ‘lib64’ on non-multilib
systems is intended. I’ve copied useful info below. Ideas?
Thanks,
Ludo’.
$ ( IFS=: ; for d in $(gcc -print-search-dirs|grep ^libraries| cut -c 13-) ; do
echo $d ; done )
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib64/x86_64-unknown-linux-gnu/4.5.0/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib64/
/nix/store/4jl83jgzaacf519h3wczgbjvqi91hfk6-glibc-2.11.1/lib/x86_64-unknown-linux-gnu/4.5.0/
/nix/store/4jl83jgzaacf519h3wczgbjvqi91hfk6-glibc-2.11.1/lib/
/nix/store/yry9ybbkij9a88z4m6hddvxcj0gkgm13-gcc-wrapper-4.5.0/bin/x86_64-unknown-linux-gnu/4.5.0/
/nix/store/yry9ybbkij9a88z4m6hddvxcj0gkgm13-gcc-wrapper-4.5.0/bin/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.5.0/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../x86_64-unknown-linux-gnu/4.5.0/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/lib/
/nix/store/8bdj9j7s75gvy26w9a6xv6qkj6s4f2c4-gcc-4.5.0/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../
$ gcc -print-multi-os-directory
../lib64
$ gcc -print-multi-os-directory -m32
../lib
$ gcc -print-multi-lib
.;
$ gcc -dumpspecs
[...]
*multilib_defaults:
m64
[...]
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’,
Ludovic Courtès <=