Bug 138742 - [multilib] libtool generated link command cannot link
[multilib] libtool generated link command cannot link
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
: 98616 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-10 17:34 EST by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-17 08:58:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
repro case for broken RPATH (537 bytes, text/plain)
2005-02-08 11:33 EST, Joe Orton
no flags Details
less typoed version (284 bytes, text/plain)
2005-02-08 11:38 EST, Joe Orton
no flags Details

  None (edit)
Description Michal Jaegermann 2004-11-10 17:34:04 EST
Description of problem:

This report is filed for 'libtool' but the issue is really with
the whole toolchain and maybe should be fixed somewhere else
(but see also the end of this report).

It appears that on x86_64 a 'libtool' file created during compilation
ends up with the following (reformatted)

sys_lib_search_path_spec=" /usr/lib/gcc/x86_64-redhat-linux/3.4.3/
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../x86_64-redhat-linux/lib/x86_64-redhat-linux/3.4.3/
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../x86_64-redhat-linux/lib/
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../x86_64-redhat-linux/3.4.3/
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../
/lib/x86_64-redhat-linux/3.4.3/
/lib/
/usr/lib/x86_64-redhat-linux/3.4.3/
/usr/lib/"

Now /usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../ is really
/usr/lib so after a removal of non-existent directories and
simplifying the above one ends up with an equivalent of

sys_lib_search_path_spec="
/usr/lib/gcc/x86_64-redhat-linux/3.4.3
/usr/lib
/lib
/usr/lib
"

The above really seems to be generated from an output of

  gcc --print-search-dirs

which on x86_64 prints for libraries roughly what we see (spec file?).

For some reasons, which are not entirely clear to me, if there is
'-lpopt' in compilation flags that gets expanded to

  ... -lbonoboui-2 -lgnome-2 /usr/lib/libpopt.so -lbonobo-2 ...

and the whole compilation ends up, predictably, with

/usr/lib/libpopt.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status

Hacking genearated 'libtool' script and putting into it

sys_lib_search_path_spec="
/usr/lib/gcc/x86_64-redhat-linux/3.4.3
/usr/lib64
/lib64
/usr/lib64
"

allows the whole compilation to succeed. /usr/lib64/libxml2.so is
another such library which gets expanded to a full path with the
later 'sys_lib_search_path_spec'.  I do not know why these and
not others.

sys_lib_dlsearch_path_spec as created by 'configure' also looks
like a potential trouble.  I got there

# Run-time system search path for libraries
sys_lib_dlsearch_path_spec="
/lib
/usr/lib
include ld.so.conf.d/*.conf
/usr/X11R6/lib
/usr/X11R6/lib64
/usr/lib64/qt-3.3/lib"

This also does not seem to be too healthy regardles of a type of
an architecture with "include" not expanded.

I believe that the issue is not limited to "rawhide".

Specifically I bumped into these troubles trying to recompile
gnumeric-1.2.13-9 so it will work with Python from the current
"rawhide".  Once I hacked 'libtool' in a gnumeric spec file
it recompiled just fine.

Version-Release number of selected component (if applicable):
libtool-1.5.10-1
gcc-3.4.3-1
Comment 1 Michal Jaegermann 2004-11-10 22:20:45 EST
It came to my mind that at least for 'sys_lib_dlsearch_path_spec'
an output of

  /sbin/ldconfig -p | sed -n 's/.*=> //p' | \
        xargs -n1 -i dirname {} | sort -u

should be good enough.  If 'sort -u' is affecting an order in
undesirable manner then piping through 'uniq' should reduce
an output size at least some (and collecting unique instances
in an order of appearance is not a rocket science either).
Comment 2 Daniel Reed 2004-11-16 18:34:06 EST
-lpopt and -lxml2 are being expanded to /usr/lib/libpopt.so and
/usr/lib/libxml2.so because /usr/lib/libpopt.la and /usr/lib/libxml2.la exist,
and they point to these .so files. The other libraries are not being expanded
because they do not have .la files installed.

This is Libtool getting multilib wrong. I have just sent a new multilib patch to
the upstream developers for review. If they have no problem with it, I will
build a new 1.5.10 with the patch (and push for a 1.5.12 release before FC4 is
released).

(NEEDINFO from external source, not reporter.)
Comment 3 Reuben Farrelly 2004-12-10 05:32:36 EST
I am having the same problem building an application on i386, so you may want to
change this to "ALL" platform ;-)
My problem is with net-snmp -lsnmp instead.
Comment 4 Daniel Reed 2005-01-20 11:01:39 EST
*** Bug 98616 has been marked as a duplicate of this bug. ***
Comment 5 Joe Orton 2005-01-20 11:13:21 EST
Please fix the regression in Raw Hide even if the upstream maintainers
have not accepted the patch yet.  I can't build subversion without the
multilib fixes and I wasted several hours working out why.
Comment 6 Reuben Farrelly 2005-02-06 06:22:15 EST
Upgrade to 1.5.12 is available at http://www.gnu.org/software/libtool/

I notice this in the changelog:

+2004-10-26  Gary Vaughan <gary@gnu.org>
+
+	* config/ltmain.in (func_mode_link): When linking an installed
+	libtool library on the command line using -lfoo we need to find
+	the library in the search paths and add it's dependency_libs to
+	the link in the conv pass so that any libtool libs listed are
+	correctly expanded in the link pass.

Can the upgrade be done to see if this fixes or changes the nature of the problem?

Comment 7 Daniel Reed 2005-02-06 11:34:38 EST
This specific change won't fix the problem. However, I am preparing a 1.5.12
build with the multilib2 patch mentioned in comment 2; it should be in rawhide
by tomorrow morning.
Comment 8 Joe Orton 2005-02-07 06:28:47 EST
This is not fixed as of libtool-1.5.12.multilib2-3.4.3, which still
adds RPATHs of /usr/lib64 on x86_64 since that path is not in
sys_lib_dlsearch_path_spec:

            # Hardcode the library path.
            # Skip directories that are in the system default run-time
            # search path.
            case " $sys_lib_dlsearch_path " in
            *" $absdir "*) ;;
            *)
              case "$compile_rpath " in
              *" $absdir "*) ;;
              *) compile_rpath="$compile_rpath $absdir"
              esac
              ;;
            esac
Comment 9 Michal Jaegermann 2005-02-07 11:45:32 EST
> ... since that path is not in sys_lib_dlsearch_path_spec

It looks to me that a way of setting sys_lib_dlsearch_path_spec
I proposed in comment #1 is still better than alternatives.
Comment 10 Daniel Reed 2005-02-07 12:38:46 EST
The rpath issue is why multilib2 is being held out of the upstream release.
There is no great way to take a list of directories and get their multilib
equivalents, and parsing the output of ldconfig isn't very reliable. I can leave
this bug open until multilib is supported in upstream Libtool, but I think this
is the best we can get at the moment.
Comment 11 Joe Orton 2005-02-07 16:09:27 EST
I'm not sure what that comment means w.r.t. getting this bug fixed.

The status quo is that the libtool package in Raw Hide is broken on x86_64 w.r.t
RPATH handling.  I cannot build the subversion package until this regression is
fixed.  The patch which was previously used in the libtool package solved this
problem.

And again: it is ideal if we can use a solution which can go upstream.  It is
sufficient if we use a solution which works.
Comment 12 Daniel Reed 2005-02-07 18:23:12 EST
I am able to build devel's subversion 1.1.3-3 on an x86_64 machine using both
1.5.10-1 and 1.5.12.multilib2-3.4.3. I get a number of FAILs in the check
section (basic_tests,  commit_tests, ...), but they all seem to be actual errors
in operation rather than executables failing to start or anything else that
would be obviously related to Libtool. What specifically are you seeing?
Comment 13 Joe Orton 2005-02-08 02:55:26 EST
The test failures are because the test binaries pick up an RPATH of /usr/lib64
and hence are linked against the old system Subversion libraries rather than the
just-built in-tree libraries.  That is the symptom of the broken RPATH handling.
Comment 14 Daniel Reed 2005-02-08 11:15:23 EST
Actually, if you go into subversion/devel/subversion-1.1.3 and type:
libtool --mode=execute ldd subversion/clients/cmdline/svn

You should see that, even with a bogus libsvn_fs_base-1.so.0 in /usr/lib64 (try
ldd subversion/clients/cmdline/.libs/svn to see the bogus link), when the
wrapper (subversion/clients/cmdline/svn) is run by itself or passed in as an
argument to another program through libtool --mode=execute, libtool makes sure
the runtime link path is correct. The above command should show
subversion/clients/cmdline/svn linked against
subversion/libsvn_fs_base/.libs/libsvn_fs_base-1.so.0, even if
/usr/lib64/libsvn_fs_base-1.so.0 exists.
Comment 15 Joe Orton 2005-02-08 11:33:03 EST
Created attachment 110807 [details]
repro case for broken RPATH

Run the above script on i386 with libdir=/usr/lib - no RPATH in created
library.

Changing to "libdir=/usr/lib64" and run on x86_64 - see RPATH in created
library.

This is the minimal repro case.
Comment 16 Joe Orton 2005-02-08 11:38:03 EST
Created attachment 110808 [details]
less typoed version
Comment 17 Joe Orton 2005-02-08 11:45:13 EST
Or from a subversion build tree... bad RPATHs demonstrated here:

bash-3.00# ./libtool --mode=execute ldd subversion/tests/libsvn_repos/repos-test
        libsvn_test_fs-1.so.0 =>
/usr/src/redhat/BUILD/subversion-1.1.3/subversion/tests/.libs/libsvn_test_fs-1.so.0
(0x0000002a9566d000)
        libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 (0x0000002a95774000)
        libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 (0x0000002a9588b000)
...

(--mode=execute is redundant in this case since the repos-test binary is built
using -no-install)
Comment 19 Michal Jaegermann 2005-02-14 20:00:55 EST
The current libtool-1.5.14.multilib2-3.4.3 from rawhide is somewhat
short on changelog saying "1.5.14 bugfix release".  But if
"multilib" in a version tag is supposed to suggest that the original
bug reported here was fixed then this, unfortunately, is not
the case.  I just tried and the same /usr/lib/libpopt.so poped out.
Comment 20 Joe Orton 2005-02-15 05:40:36 EST
libtool has now been reverted to use the old multilib patch; built as
libtool-1.5.14.multilib2-4 in Raw Hide.
Comment 21 Michal Jaegermann 2005-02-16 18:03:42 EST
$ rpm -q libtool
libtool-1.5.14.multilib2-4

and on an attempt to 'rpmbuild --rebuild some.src.rpm' I am seeing
in a link command:

... -lICE -lbonoboui-2 -lgnome-2 /usr/lib/libpopt.so -lgnomevfs-2 ...

and, obviously enough,

/usr/lib/libpopt.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status

What gives?  The sorce rpm I was trying was actually
gnumeric-1.2.13-9.src.rpm which I happened to have laying around.
Comment 22 Joe Orton 2005-02-17 08:58:15 EST
gnumeric.spec is building using the version of libtool shipped in the
tarball not the system tarball; it should do

libtoolize --force --copy && aclocal && autoconf

or suchlike before %configure; can you file a bug against gnumeric for
that issue?  

Please file new libtool bugs and CC me if there are any new multilib
regressions in libtool, too...

Note You need to log in before you can comment on or make changes to this bug.