grep 3.3.5 /usr/bin/libtool predep_objects="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtbeginS.o" postdep_objects="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtendS.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crtn.o" compiler_lib_search_path="-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../.." Symptom: apmd doesn't build when doing a simple libtool link : libtool --quiet --mode=link gcc -o libapm.la apmlib.lo -rpath /usr/lib -version-info 1:0 i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crti.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtbeginS.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtendS.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crtn.o: No such file or directory Reproducible: Always Steps to Reproduce: 1. 2. 3.
Not present in the latest / 1.5.14 / version of libtool.
I'm seeing the behavior with libtool-1.5.14 as well. From this morning's emerge -uDv world beldin root # genlop -l | grep "Apr 11" Mon Apr 11 08:32:07 2005 >>> sys-devel/libtool-1.5.14 Mon Apr 11 09:34:53 2005 >>> sys-devel/gcc-3.3.5.20050130-r1 beldin root # grep 3.3.5 /usr/bin/libtool predep_objects="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtbeginS.o" postdep_objects="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtendS.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crtn.o" compiler_lib_search_path="-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../.." beldin root # ebuild /usr/portage/sys-apps/apmd/apmd-3.2.1_p4.ebuild compile >>> md5 src_uri ;-) apmd_3.2.1.orig.tar.gz >>> md5 src_uri ;-) apmd_3.2.1-4.diff.gz >>> Checking apmd_3.2.1.orig.tar.gz's mtime... >>> Checking apmd_3.2.1-4.diff.gz's mtime... >>> WORKDIR is up-to-date, keeping... libtool --quiet --mode=link gcc -o libapm.la apmlib.lo -rpath /usr/lib -version-info 1:0 i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crti.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtbeginS.o: Nosuch file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtendS.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../crtn.o: No such file or directory make: *** [libapm.la] Error 1 Re-emerging libtool fixes the problem, until the next gcc upgrade.
This problem still seems to be present in libtool 1.5.18-r1. At least, I get the same symptoms trying to compile apmd 3.2.1_p4. apmd 3.0.2-r3 compiles without a problem, however.
I just sadly discovered this while my system was merging package by package for gnome install.. Exactly the same... I have 3.3.6 GCC, and everything on my system latest Portage for x86 branch.. The only way i was able to get arround this was by making a system link from the old gcc dir to the new one.. Hope this will get fixed, as this is a big problem if you intend on installing GNOME/etc fresh.. Without knowning how to fix it..
libtool-1.5.20 still has the gcc version "compiled-in" (*g*). Maybe anyone reading this is also having trouble with Your gcc-update -- a workaround might be in Bug#105141, Comments 5-7... btw: gcc-config does not change libtool - maybe it should?
Created attachment 70208 [details, diff] libtool-1.5.20-dynamic-shared-info.patch this should cover the most common CXX case
this isnt that critical an issue as all proper autotooled packages nowadays bundle libtool in with them thus the system libtool (/usr/bin/libtool) is never run
Well, I've just come across this problem with libtool-1.5.22 whilst trying to emerge apmd-3.2.2_p5 - looks like that one does use /usr/bin/libtool ... Trivially fixed by re-emerging libtool, of course. Phil
I have the same problem with older gcc version in /usr/bin/libtool breaking build of sg3_utils and bind-utils. My libtool ebuild is libtool-1.5.22. I think an easy solution would be to enhance the /sbin/fix_libtool_files.sh to search&replace the gcc version number also from /usr/bin/libtool
also happened to me with libtool-1.5.22 when building dev-libs/cdk
Also happens with sg3_utils
Can someone who *is* (not was) affected by this bug please attach their /usr/bin/libtool?
(In reply to comment #12) > Can someone who *is* (not was) affected by this bug please attach their > /usr/bin/libtool? > I will. My libtool (1.5.22) was installed while i was using gcc-4.1.0, whereas i now have version 4.1.1. Note that it had not really been a problem so far (as SpanKY said, most packages don't use /usr/bin/libtool), but it still breaks a few packages: % ebuild sys-apps/sg3_utils/sg3_utils-1.20-r1.ebuild compile <...snip...> i686-pc-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbeginS.o .libs/sg_lib.o .libs/sg_cmds.o .libs/sg_pt_linux.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crtn.o -Wl,-soname -Wl,libsgutils.so.1 -o .libs/libsgutils.so.1.0.0 i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crti.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbeginS.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtendS.o: No such file or directory i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crtn.o: No such file or directory make: *** [libsgutils.la] Error 1
Created attachment 88745 [details] /usr/bin/libtool From libtool-1.5.22 installed with gcc-4.1.0. % grep 4.1.0 /usr/bin/libtool sys_lib_search_path_spec=" /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../ /lib/i686-pc-linux-gnu/4.1.0/ /lib/ /usr/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/" sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib //usr//lib/opengl/xorg-x11/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc/i686-pc-linux-gnu/4.1.0 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6 /usr/lib/nspr /usr/lib/nss /usr/lib /usr/lib/openmotif-2.2 /opt/sun-jdk-1.4.2.10/jre/lib/i686/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/native_threads/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/client/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/server/ /usr/kde/3.5/lib /usr/qt/3/lib /usr/games/lib /usr/lib/libstdc++-v3/ " predep_objects="/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbeginS.o" postdep_objects="/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.." sys_lib_search_path_spec=" /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../ /lib/i686-pc-linux-gnu/4.1.0/ /lib/ /usr/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/" sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib //usr//lib/opengl/xorg-x11/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc/i686-pc-linux-gnu/4.1.0 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6 /usr/lib/nspr /usr/lib/nss /usr/lib /usr/lib/openmotif-2.2 /opt/sun-jdk-1.4.2.10/jre/lib/i686/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/native_threads/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/client/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/server/ /usr/kde/3.5/lib /usr/qt/3/lib /usr/games/lib /usr/lib/libstdc++-v3/ " sys_lib_search_path_spec=" /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../ /lib/i686-pc-linux-gnu/4.1.0/ /lib/ /usr/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/" sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib //usr//lib/opengl/xorg-x11/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc/i686-pc-linux-gnu/4.1.0 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6 /usr/lib/nspr /usr/lib/nss /usr/lib /usr/lib/openmotif-2.2 /opt/sun-jdk-1.4.2.10/jre/lib/i686/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/native_threads/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/client/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/server/ /usr/kde/3.5/lib /usr/qt/3/lib /usr/games/lib /usr/lib/libstdc++-v3/ " sys_lib_search_path_spec=" /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../i686-pc-linux-gnu/4.1.0/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../ /lib/i686-pc-linux-gnu/4.1.0/ /lib/ /usr/lib/i686-pc-linux-gnu/4.1.0/ /usr/lib/" sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib //usr//lib/opengl/xorg-x11/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc/i686-pc-linux-gnu/4.1.0 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6 /usr/lib/nspr /usr/lib/nss /usr/lib /usr/lib/openmotif-2.2 /opt/sun-jdk-1.4.2.10/jre/lib/i686/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/native_threads/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/client/ /opt/sun-jdk-1.4.2.10/jre/lib/i686/server/ /usr/kde/3.5/lib /usr/qt/3/lib /usr/games/lib /usr/lib/libstdc++-v3/ "
dev-libs/cdb-5.0.20060220 broke here. /usr/bin/libtool had version 3.4.5 while I had 3.4.6 and 4.1.1 on my system.
still status "new"? Any possibility to identify packages without "integrated libtool"?
ive posted a patch; not a single person has tested it i'm not committing this patch without any sort of feedback
I tested the patch by doing the following and it is working. quickpkg =sys-devel/gcc-3.4.6-r1 quickpkg =sys-devel/gcc-4.1.1 emerge --unmerge =sys-devel/gcc-4.1.1 gcc-config i686-pc-linux-gnu-3.4.6 source /etc/profile emerge -v1 libtool (unpatched) emerge -Kv1 =sys-devel/gcc-4.1.1 emerge --unmerge =sys-devel/gcc-3.4.6-r1 gcc-config i686-pc-linux-gnu-4.1.1 source /etc/profile emerge -v1 sg3_utils (FAILED) emerge -Kv1 =sys-devel/gcc-3.4.6-r1 emerge --unmerge =sys-devel/gcc-4.1.1 gcc-config i686-pc-linux-gnu-3.4.6 source /etc/profile emerge -v1 libtool (patched in overlay) emerge -Kv1 =sys-devel/gcc-4.1.1 emerge --unmerge =sys-devel/gcc-3.4.6-r1 gcc-config i686-pc-linux-gnu-4.1.1 source /etc/profile emerge -v1 sg3_utils (SUCCESS)
vapier: fuzzyray tested your patch years ago, please integrate or back out?
i'm pretty on the fence about this. no package should be using /usr/bin/libtool anyways when building in the tree. i'm also not sure if the patch would apply to the latest libtool-2.x.
*** Bug 451902 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > i'm pretty on the fence about this. no package should be using > /usr/bin/libtool anyways when building in the tree. > In that case, have you think on stopping to provide /usr/bin/libtool with libtool package? (or rename it) That way we would catch in tree packages wanting to run it and that could be affected by this bug (if still valid with libtool-2) > i'm also not sure if the patch would apply to the latest libtool-2.x.
(In reply to comment #22) realistically, there are a bunch of packages that run libtool. some use autotools, but not all. so getting them to integrate a local libtool would be pretty hard. and it wouldn't help with random packages people download and compile themselves. at least for the tree, we'd probably have to implement an eclass to do it :x. although now that i say that last bit out loud ...
Created attachment 335668 [details, diff] libtool-2.4.2-dynamic-gcc.patch annoyingly, i finished writing this patch, but now can't get libtool to trigger problems for me anymore. maybe it's gotten more intelligent since. this version should work between any gcc version.
Created attachment 335670 [details, diff] libtool-2.4.2.ebuild.patch this patch has the advantage in that it only affects /usr/bin/libtool. unlike the previous attempt, libtool.m4/etc... that get copied via elibtoolize are unchanged. that means we don't have to worry about bleeding into pkgs.
(In reply to comment #24) > Created attachment 335668 [details, diff] [details, diff] > libtool-2.4.2-dynamic-gcc.patch > > annoyingly, i finished writing this patch, but now can't get libtool to > trigger problems for me anymore. maybe it's gotten more intelligent since. > > this version should work between any gcc version. Do you want me to check anything leading us to finally solve this and stop telling people to rebuild libtool after gcc switch? :)
(In reply to comment #26) if someone could post an example that still fails for them when libtool was built against a gcc that is no longer installed, that'd be great
(In reply to SpanKY from comment #27) > (In reply to comment #26) > > if someone could post an example that still fails for them when libtool was > built against a gcc that is no longer installed, that'd be great libtool: link: x86_64-pc-linux-gnu-g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/crtbeginS.o cctbx/eltbx/.libs/basic.o cctbx/eltbx/xray_scattering/.libs/it1992.o cctbx/eltbx/xray_scattering/.libs/wk1995.o cctbx/eltbx/xray_scattering/.libs/n_gaussian_raw.o cctbx/eltbx/xray_scattering/.libs/n_gaussian.o cctbx/eltbx/.libs/fp_fdp.o cctbx/eltbx/.libs/henke.o cctbx/eltbx/.libs/henke_tables_01_12.o cctbx/eltbx/.libs/henke_tables_13_24.o cctbx/eltbx/.libs/henke_tables_25_36.o cctbx/eltbx/.libs/henke_tables_37_48.o cctbx/eltbx/.libs/henke_tables_49_60.o cctbx/eltbx/.libs/henke_tables_61_72.o cctbx/eltbx/.libs/henke_tables_73_84.o cctbx/eltbx/.libs/henke_tables_85_92.o cctbx/eltbx/.libs/icsd_radii.o cctbx/eltbx/.libs/covalent_radii.o cctbx/eltbx/.libs/neutron.o cctbx/eltbx/.libs/sasaki.o cctbx/eltbx/.libs/sasaki_tables_01_12.o cctbx/eltbx/.libs/sasaki_tables_13_24.o cctbx/eltbx/.libs/sasaki_tables_25_36.o cctbx/eltbx/.libs/sasaki_tables_37_48.o cctbx/eltbx/.libs/sasaki_tables_49_60.o cctbx/eltbx/.libs/sasaki_tables_61_72.o cctbx/eltbx/.libs/sasaki_tables_73_82.o cctbx/eltbx/.libs/tiny_pse.o cctbx/eltbx/.libs/wavelengths.o cctbx/eltbx/electron_scattering/.libs/peng1996.o cctbx/miller/.libs/asu.o cctbx/miller/.libs/bins.o cctbx/miller/.libs/index_generator.o cctbx/miller/.libs/index_span.o cctbx/miller/.libs/match_bijvoet_mates.o cctbx/miller/.libs/match_indices.o cctbx/miller/.libs/match_multi_indices.o cctbx/miller/.libs/sym_equiv.o cctbx/sgtbx/.libs/bricks.o cctbx/sgtbx/.libs/change_of_basis_op.o cctbx/sgtbx/.libs/find_affine.o cctbx/sgtbx/.libs/group_codes.o cctbx/sgtbx/.libs/hall_in.o cctbx/sgtbx/.libs/lattice_tr.o cctbx/sgtbx/.libs/lattice_symmetry.o cctbx/sgtbx/.libs/miller.o cctbx/sgtbx/.libs/reciprocal_space_asu.o cctbx/sgtbx/.libs/reciprocal_space_ref_asu.o cctbx/sgtbx/.libs/rot_mx.o cctbx/sgtbx/.libs/rot_mx_info.o cctbx/sgtbx/.libs/row_echelon_solve.o cctbx/sgtbx/.libs/rt_mx.o cctbx/sgtbx/.libs/select_generators.o cctbx/sgtbx/.libs/seminvariant.o cctbx/sgtbx/.libs/site_symmetry.o cctbx/sgtbx/.libs/space_group.o cctbx/sgtbx/.libs/space_group_type.o cctbx/sgtbx/.libs/symbols.o cctbx/sgtbx/.libs/tensor_rank_2.o cctbx/sgtbx/.libs/tr_group.o cctbx/sgtbx/.libs/tr_vec.o cctbx/sgtbx/.libs/utils.o cctbx/sgtbx/.libs/wyckoff.o cctbx/sgtbx/reference_settings/.libs/hall_symbol_table.o cctbx/sgtbx/reference_settings/.libs/matrix_group_code_table.o cctbx/sgtbx/reference_settings/.libs/normalizer.o cctbx/sgtbx/reference_settings/.libs/wyckoff.o cctbx/uctbx/.libs/uctbx.o cctbx/uctbx/.libs/spoil_optimization.o cctbx/uctbx/.libs/crystal_orientation.o -Llib -L/var/tmp/portage/sci-libs/cctbx-2013.02.27.0005/work/cctbx_sources/lib -Llib/usr/lib64 -L/var/tmp/portage/sci-libs/cctbx-2013.02.27.0005/work/cctbx_sources/lib/usr/lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib64/crtn.o -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-soname -Wl,libcctbx.so.0 -o lib/.libs/libcctbx.so.0.0.0 x86_64-pc-linux-gnu-g++: error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/crtbeginS.o: No such file or directory x86_64-pc-linux-gnu-g++: error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/crtendS.o: No such file or directory scons: *** [lib/libcctbx.la] Error 1
This is the sci-libs/cctbx testing version from sci-overlay.
Created attachment 350228 [details] build.log
Emerging dev-libs/crypto++-5.6.2 failed, since /usr/bin/libtool still had gcc 4.5.3 paths in it. But gcc 4.5.3 was updated to 4.6.3 a long time ago. Re-emerging libtool fixed it.
Created attachment 352470 [details] dev-libs/crypto++-5.6.2 build log Build log from dev-libs/crypto++-5.6.2 which fails until libtool is rebuilt to include the correct gcc path.
(In reply to Paul Varner from comment #32) > Build log from dev-libs/crypto++-5.6.2 which fails until libtool is rebuilt > to include the correct gcc path. Same here. build.log is pretty much identical.
(In reply to SpanKY from comment #27) > (In reply to comment #26) > > if someone could post an example that still fails for them when libtool was > built against a gcc that is no longer installed, that'd be great Just hit bug 403467
(In reply to SpanKY from comment #27) > (In reply to comment #26) > > if someone could post an example that still fails for them when libtool was > built against a gcc that is no longer installed, that'd be great Do you want any more information? (I am still able to reproduce with crypto++ just now) Thanks
(In reply to Pacho Ramos from comment #35) no, i don't need anymore info. i did fix crypto++ recently though so it doesn't need the system libtool ... it generates a local copy & uses that like a proper package.
It worked, thanks :D
*** Bug 515054 has been marked as a duplicate of this bug. ***
Current libtool-2.4.6 is still carrying the hardcoded old paths: # grep 4.8.3 /usr/bin/libtool sys_lib_search_path_spec="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3 /usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib /usr/lib /lib " sys_lib_dlsearch_path_spec="/lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 /lib32 /usr/lib32 /usr/local/lib32 /lib /usr/lib /usr/local/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3 /usr/lib32/opengl/xorg-x11/lib /usr/lib64/opengl/xorg-x11/lib /usr/x86_64-pc-linux-gnu/lib /usr/lib64/qt4 /usr/lib32/qt4 /usr/lib/qt4 /usr/games/lib64 /usr/games/lib32 /usr/games/lib /usr/lib64/R/lib /usr/lib64/fltk-1 " compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64 /lib/../lib64 /usr/lib/../lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../.." predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/crtbeginS.o" postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../.." compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64 /lib/../lib64 /usr/lib/../lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../.." predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/crtbeginS.o" postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../.." Could then the patches from comment #24 and comment #25 be applied finally? Otherwise, as we keep the broken /usr/bin/libtool, we are simply waiting for any random package (even manually compiled, or from the main tree) to hit this bug sooner or later and we will always need to rely on people remembering to manually rebuild libtool after upgrading gcc :/ Thanks a lot
Any news on this?
I'm guessing that after almost 15 years this is still an issue: # grep 8.2.0 /usr/bin/libtool sys_lib_search_path_spec="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 /usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib /usr/lib /lib " sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/32 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0 /usr/lib/llvm/6/lib64 /lib64 /usr/lib64 /usr/local/lib64 /lib32 /usr/lib32 /usr/local/lib32 /lib /usr/lib /usr/local/lib /usr/lib64/rust-1.29.1 /usr/lib64/fltk " compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 /lib/../lib64 /usr/lib/../lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.." predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbeginS.o" postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.." compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 /lib/../lib64 /usr/lib/../lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.." predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbeginS.o" postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/crtn.o" compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.." Are the six year old patches still in need of testing?
ping
Tomsfastmath has a makefile-only build system but uses libtool to version its shared library. I'm guessing that the other victims of this problem are similar. When a package has a handwritten makefile, we wind up exporting e.g. CC and CFLAGS, or passing them directly to Make with "make FOO=bar", to override the upstream defaults. In situations like that, all we really need is for /usr/bin/libtool to respect CC and friends from the environment. For example, to fix the linked tomsfastmath bug, it suffices to replace CC="x86_64-pc-linux-gnu-gcc" with : ${CC:="x86_64-pc-linux-gnu-gcc"} in my /usr/bin/libtool. (That only sets the variable if it is not already set.) Having done that, I am free to break GCC and then compile tomsfastmath with CC=clang. If the same can be done for all of the other tc-getFOO variables, perhaps that is a less-invasive solution.
reping
*** Bug 782556 has been marked as a duplicate of this bug. ***
See https://archives.gentoo.org/gentoo-dev/message/abf2e3c467542c9958107fbc4a716ef9 for a proposal on this on gentoo-dev ~recently. From mgorny: >I can think of two ways of solving it: > >1. We could patch system-installed libtool to respect environment >variables such as CC, CXX, etc. This will probably require carrying >a (possibly non-trivial) patch forever. On the bright side, libtool is >not exactly a package seeing frequent releases. I mean, the current >version is from 2015. > >2. We could regenerate libtool and force local instance of libtool >in the packages needing it. The main advantage of this is that it's >a no-brainer. I could make a quick eclass that does configure a local >instance and prepends it into PATH.
Nothing really happened because apparently slibtool was just around the corner at the time.
(In reply to Michał Górny from comment #47) > Nothing really happened because apparently slibtool was just around the > corner at the time. I suspect that's not going to happen any time soon, given we haven't figured out a solution to "what if the package calls /usr/bin/libtool instead of generating one" for slibtool (it has a different -shared binary which must be called depending on the build system/binaries being produced). A fair amount of the remaining slibtool bugs are actually just "calls libtool directly". But not convinced we want to go through and autotools them all properly. Many of them are "simple Makefile" projects.
(In reply to Sam James from comment #48) ebuilds that call /usr/bin/libtool directly are broken. they don't respect the active toolchain settings, so most likely broken with cross-compiling & multiabi.
