Subject: bug#8726: rpath encoded in binary linking a .la-.so file

From: Jan Engelhardt <[email-masked]>
Date: Tue, 24 May 2011 15:16:36 +0200 (CEST)

On Tuesday 2011-05-24 15:01, Peter Volkov wrote via private mail:
>
>>>Final ipset binary is linked with:
>>>/bin/sh ../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc
>>>-std=gnu99  -O2 -DNDEBUG -O2 -pipe -march=native -mtune=native -ggdb
>>>-static -Wl,--as-needed,--hash-style=gnu -o ipset ipset.o
>>>[...] ../lib/libipset.la 
>>>libtool: link: x86_64-pc-linux-gnu-gcc -std=gnu99 -O2 -DNDEBUG -O2 -pipe
>>>-march=native -mtune=native -ggdb -Wl,--as-needed -Wl,--hash-style=gnu
>>>-o ipset ipset.o [...]  ../lib/.libs/libipset.so -L/lib64 -lmnl
>>>-Wl,-rpath -Wl,/vt/gentoo/work/ipset-6.6/lib/.libs
>>>[and I wonder where the rpath comes from]

I investigated into --disable-static builds, and it looks like a libtool 
bug to me.

A testcase is attached for the libtool devs, and so this goes Cc there.

DESC: If -static is specified at the libtool command line, it ignores 
the fact that it may nevertheless has to link against a .la/.so file 
(e.g. due to ./configure --disable-static or AC_DISABLE_STATIC), and 
thus wrongly encodes an rpath into the binary that I believe it should 
not. What libtool should have done is to create the helper script as it 
would when -static was not specified.