Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 88596 - sys-devel/libtool stores gcc-path internally. sometimes a bad thing due to gcc update
Summary: sys-devel/libtool stores gcc-path internally. sometimes a bad thing due to g...
Status: IN_PROGRESS
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major with 2 votes (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 451902 515054 782556 (view as bug list)
Depends on:
Blocks: 403467
  Show dependency tree
 
Reported: 2005-04-10 08:28 UTC by Spider (RETIRED)
Modified: 2022-02-21 05:05 UTC (History)
15 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
libtool-1.5.20-dynamic-shared-info.patch (libtool-1.5.20-dynamic-shared-info.patch,3.28 KB, patch)
2005-10-09 03:05 UTC, SpanKY
Details | Diff
/usr/bin/libtool (libtool,236.59 KB, text/plain)
2006-06-08 23:09 UTC, TGL
Details
libtool-2.4.2-dynamic-gcc.patch (libtool-2.4.2-dynamic-gcc.patch,1.88 KB, patch)
2013-01-15 04:15 UTC, SpanKY
Details | Diff
libtool-2.4.2.ebuild.patch (libtool-2.4.2.ebuild.patch,1.32 KB, patch)
2013-01-15 04:24 UTC, SpanKY
Details | Diff
build.log (cctbx-2013.02.27.0005:20130605-164818.log,417.86 KB, text/x-log)
2013-06-05 17:01 UTC, Justin Lecher (RETIRED)
Details
dev-libs/crypto++-5.6.2 build log (build.log,43.41 KB, text/x-log)
2013-07-02 21:18 UTC, Paul Varner (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Spider (RETIRED) gentoo-dev 2005-04-10 08:28:22 UTC
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.
Comment 1 Spider (RETIRED) gentoo-dev 2005-04-11 02:32:27 UTC
Not present in the latest / 1.5.14 / version of libtool.
Comment 2 Paul Varner (RETIRED) gentoo-dev 2005-04-11 08:15:27 UTC
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.
Comment 3 Lee Davis 2005-09-15 20:42:47 UTC
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.
Comment 4 Ryan 2005-09-25 14:59:45 UTC
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..
Comment 5 Mark Dominik Bürkle 2005-09-29 17:29:41 UTC
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?
Comment 6 SpanKY gentoo-dev 2005-10-09 03:05:21 UTC
Created attachment 70208 [details, diff]
libtool-1.5.20-dynamic-shared-info.patch

this should cover the most common CXX case
Comment 7 SpanKY gentoo-dev 2006-01-13 03:36:56 UTC
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
Comment 8 Phil Richards 2006-02-12 02:15:57 UTC
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
Comment 9 Mikko Tiihonen 2006-02-25 01:28:56 UTC
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
Comment 10 matejcik 2006-05-07 04:23:51 UTC
also happened to me with libtool-1.5.22 when building dev-libs/cdk
Comment 11 Chris Bainbridge (RETIRED) gentoo-dev 2006-05-24 05:38:31 UTC
Also happens with sg3_utils
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2006-06-08 14:00:24 UTC
Can someone who *is* (not was) affected by this bug please attach their /usr/bin/libtool?
Comment 13 TGL 2006-06-08 23:07:40 UTC
(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
Comment 14 TGL 2006-06-08 23:09:06 UTC
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/ "
Comment 15 Georgi Georgiev 2006-08-11 10:43:43 UTC
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.



Comment 16 Mark Dominik Bürkle 2006-09-29 05:03:09 UTC
still status "new"?
Any possibility to identify packages without "integrated libtool"?
Comment 17 SpanKY gentoo-dev 2006-09-29 12:26:57 UTC
ive posted a patch; not a single person has tested it

i'm not committing this patch without any sort of feedback
Comment 18 Paul Varner (RETIRED) gentoo-dev 2006-09-29 16:25:21 UTC
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)
Comment 19 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-12-07 07:02:23 UTC
vapier: fuzzyray tested your patch years ago, please integrate or back out?
Comment 20 SpanKY gentoo-dev 2008-12-07 07:33:55 UTC
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.
Comment 21 SpanKY gentoo-dev 2013-01-14 16:32:52 UTC
*** Bug 451902 has been marked as a duplicate of this bug. ***
Comment 22 Pacho Ramos gentoo-dev 2013-01-14 19:58:42 UTC
(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.
Comment 23 SpanKY gentoo-dev 2013-01-15 00:16:06 UTC
(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 ...
Comment 24 SpanKY gentoo-dev 2013-01-15 04:15:17 UTC
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.
Comment 25 SpanKY gentoo-dev 2013-01-15 04:24:41 UTC
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.
Comment 26 Pacho Ramos gentoo-dev 2013-01-20 11:37:07 UTC
(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? :)
Comment 27 SpanKY gentoo-dev 2013-01-20 17:41:05 UTC
(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
Comment 28 Justin Lecher (RETIRED) gentoo-dev 2013-06-05 17:00:36 UTC
(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
Comment 29 Justin Lecher (RETIRED) gentoo-dev 2013-06-05 17:01:10 UTC
This is the sci-libs/cctbx testing version from sci-overlay.
Comment 30 Justin Lecher (RETIRED) gentoo-dev 2013-06-05 17:01:36 UTC
Created attachment 350228 [details]
build.log
Comment 31 Sven 2013-06-27 19:08:21 UTC
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.
Comment 32 Paul Varner (RETIRED) gentoo-dev 2013-07-02 21:18:55 UTC
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.
Comment 33 jannis 2013-11-14 21:07:14 UTC
(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.
Comment 34 Pacho Ramos gentoo-dev 2013-11-23 12:06:53 UTC
(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
Comment 35 Pacho Ramos gentoo-dev 2013-12-22 09:07:56 UTC
(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
Comment 36 SpanKY gentoo-dev 2013-12-26 08:57:49 UTC
(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.
Comment 37 Pacho Ramos gentoo-dev 2013-12-26 09:42:34 UTC
It worked, thanks :D
Comment 38 SpanKY gentoo-dev 2014-08-01 11:20:47 UTC
*** Bug 515054 has been marked as a duplicate of this bug. ***
Comment 39 Pacho Ramos gentoo-dev 2015-10-02 09:12:23 UTC
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
Comment 40 Pacho Ramos gentoo-dev 2017-11-19 17:17:41 UTC
Any news on this?
Comment 41 BobbyK 2019-03-02 21:59:10 UTC
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?
Comment 42 Agostino Sarubbo gentoo-dev 2020-10-01 12:22:55 UTC
ping
Comment 43 Michael Orlitzky gentoo-dev 2020-10-03 01:59:16 UTC
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.
Comment 44 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-01-06 00:02:55 UTC
reping
Comment 45 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-04-13 13:55:14 UTC
*** Bug 782556 has been marked as a duplicate of this bug. ***
Comment 46 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-06-12 11:45:43 UTC
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.
Comment 47 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-06-12 12:20:06 UTC
Nothing really happened because apparently slibtool was just around the corner at the time.
Comment 48 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-04 23:25:34 UTC
(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.
Comment 49 SpanKY gentoo-dev 2021-11-05 10:59:25 UTC
(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.