Bug#888059: libtool: the generated run path order is incorrect, yielding failures with "make check"

2022-11-18 Thread Vincent Lefevre
Control: found -1 2.4.7-4
Control: retitle -1 libtool: the generated run path order is incorrect, 
yielding failures with "make check", e.g. for Solaris

Updated the title to mention Solaris, so that this bug report can be
found more easily (I currently have this issue only with Solaris/x86).

On 2018-01-23 01:56:36 +0100, Vincent Lefevre wrote:
> I've generated a MPFR 4.0.1-rc1 tarball from Debian and tested it
> on Solaris. The result: all tests from "make check" fail because
> the tested MPFR version is the one installed on the system instead
> of the local one. I've looked at one of the "link" commands:
> 
> /bin/bash ../libtool  --tag=CC--mode=link gcc  -Wall -Wmissing-prototypes 
> -Wpointer-arith -g -O2 -ffloat-store  -no-install -L../src/.libs  -o tadd 
> tadd.o libfrtests.la -lm -lquadmath ../src/libmpfr.la -lgmp
> libtool: link: gcc -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 
> -ffloat-store -o tadd tadd.o  -L../src/.libs ./.libs/libfrtests.a 
> /opt/csw/lib/libquadmath.so -lm ../src/.libs/libmpfr.so -lgmp -R/opt/csw/lib 
> -R/tmp/mpfrtests-vincent-15114/obj/src/.libs -R/opt/csw/lib -R/usr/local/lib
> 
> which is wrong! Indeed, one has the system -R/opt/csw/lib before
> the local -R/tmp/mpfrtests-vincent-15114/obj/src/.libs, so that the
> system MPFR library has the precedence over the local one (the one
> that should be tested).

Now with GNU MPFR 4.1.1:

FAIL: tversion
Incorrect MPFR version! (4.1.1 header vs 4.1.0 library)
[...]

and I can see

/usr/xpg4/bin/sh ../libtool  --tag=CC--mode=link /opt/csw/bin/gcc-5.2  
-Wall -Wmissing-prototypes -Wpointer-arith -O2 -pipe -fno-omit-frame-pointer 
-m32 -march=pentiumpro -ffloat-store  -no-install -L../src/.libs  -o tzeta_ui 
tzeta_ui.o libfrtests.la -lm -lquadmath ../src/libmpfr.la -lgmp
libtool: link: /opt/csw/bin/gcc-5.2 -Wall -Wmissing-prototypes -Wpointer-arith 
-O2 -pipe -fno-omit-frame-pointer -m32 -march=pentiumpro -ffloat-store -o 
tzeta_ui tzeta_ui.o  -L../src/.libs ./.libs/libfrtests.a 
/opt/csw/lib/libquadmath.so -lm ../src/.libs/libmpfr.so -lgmp -R/opt/csw/lib 
-R/home/vincent/mpfrtests-unstable10x-3216/obj/src/.libs -R/opt/csw/lib 
-R/usr/local/lib

i.e. the failure comes from the fact that -R/opt/csw/lib appears
before -R/home/vincent/mpfrtests-unstable10x-3216/obj/src/.libs,
so that /opt/csw/lib/libmpfr.so is used instead of the version
that has just been built under mpfrtests-unstable10x-3216.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#888059: libtool: the generated run path order is incorrect, yielding failures with "make check"

2018-01-22 Thread Vincent Lefevre
Package: libtool
Version: 2.4.6-2
Severity: important
Tags: upstream
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30222

I've generated a MPFR 4.0.1-rc1 tarball from Debian and tested it
on Solaris. The result: all tests from "make check" fail because
the tested MPFR version is the one installed on the system instead
of the local one. I've looked at one of the "link" commands:

/bin/bash ../libtool  --tag=CC--mode=link gcc  -Wall -Wmissing-prototypes 
-Wpointer-arith -g -O2 -ffloat-store  -no-install -L../src/.libs  -o tadd 
tadd.o libfrtests.la -lm -lquadmath ../src/libmpfr.la -lgmp
libtool: link: gcc -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 
-ffloat-store -o tadd tadd.o  -L../src/.libs ./.libs/libfrtests.a 
/opt/csw/lib/libquadmath.so -lm ../src/.libs/libmpfr.so -lgmp -R/opt/csw/lib 
-R/tmp/mpfrtests-vincent-15114/obj/src/.libs -R/opt/csw/lib -R/usr/local/lib

which is wrong! Indeed, one has the system -R/opt/csw/lib before
the local -R/tmp/mpfrtests-vincent-15114/obj/src/.libs, so that the
system MPFR library has the precedence over the local one (the one
that should be tested).

$ ldd tadd
libquadmath.so.0 =>  /opt/csw/lib/libquadmath.so.0
libm.so.2 => /lib/libm.so.2
libmpfr.so.6 =>  /opt/csw/lib/libmpfr.so.6
libgmp.so.10 =>  /opt/csw/lib/libgmp.so.10
libc.so.1 => /lib/libc.so.1
libgcc_s.so.1 => /opt/csw/lib/i386/libgcc_s.so.1

Note: MPFR was configured with

  ../mpfr-4.0.1-rc1/configure --enable-assert=full

In the generated "libtool" script:

# Compile-time system search path for libraries.
sys_lib_search_path_spec="/opt/csw/lib/gcc/i386-pc-solaris2.10/5.5.0 
/opt/csw/i386-pc-solaris2.10/lib /opt/csw/lib /lib /usr/lib "

# Detected run-time system search path for libraries.
sys_lib_dlsearch_path_spec="/lib /usr/lib"

and the environment doesn't contain anything that would cause the
error.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtool depends on:
ii  autotools-dev   20171216.1
ii  clang-3.6 [c-compiler]  1:3.6.2-3
ii  clang-3.7 [c-compiler]  1:3.7.1-3+b2
ii  clang-3.8 [c-compiler]  1:3.8.1-27
ii  clang-3.9 [c-compiler]  1:3.9.1-19
ii  clang-4.0 [c-compiler]  1:4.0.1-8
ii  cpp 4:7.2.0-1d1
ii  file1:5.32-1
ii  gcc [c-compiler]4:7.2.0-1d1
ii  gcc-4.8 [c-compiler]4.8.5-4
ii  gcc-4.9 [c-compiler]4.9.4-2
ii  gcc-5 [c-compiler]  5.5.0-6
ii  gcc-6 [c-compiler]  6.4.0-11
ii  gcc-7 [c-compiler]  7.2.0-19
ii  libc6-dev [libc-dev]2.26-4
ii  tcc [c-compiler]0.9.27~git20161217.cd9514ab-3

Versions of packages libtool recommends:
ii  libltdl-dev  2.4.6-2+local1

Versions of packages libtool suggests:
ii  autoconf 2.69-11+local1
ii  automake [automaken] 1:1.15.1-3
pn  gcj-jdk  
ii  gfortran 4:7.2.0-1d1
ii  gfortran-5 [fortran95-compiler]  5.5.0-6
ii  gfortran-6 [fortran95-compiler]  6.4.0-11
ii  gfortran-7 [fortran95-compiler]  7.2.0-19
ii  libtool-doc  2.4.6-2

-- no debconf information