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
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).
-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.)
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.
*** Bug 98616 has been marked as a duplicate of this bug. ***
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.
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> + + * 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?
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.
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
> ... 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.
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.
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.
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?
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.
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.
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.
Created attachment 110808 [details] less typoed version
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)
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.
libtool has now been reverted to use the old multilib patch; built as libtool-1.5.14.multilib2-4 in Raw Hide.
$ 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.
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...