Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 81518 - Emerging jpeg-6b-r4 fails while linking due to ebuild gettin wrong version info for gcc
Summary: Emerging jpeg-6b-r4 fails while linking due to ebuild gettin wrong version in...
Status: RESOLVED DUPLICATE of bug 80424
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
: 87105 (view as bug list)
Depends on:
Reported: 2005-02-10 10:35 UTC by Evan Borgstrom
Modified: 2005-07-17 13:06 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Evan Borgstrom 2005-02-10 10:35:26 UTC
Emerge'ing anything that doesn't use the libtool/toolchain-func eclass's works as expected (I've emerge a bunch of things like apache and postgresql) but trying to emerge jpeg-6b-r4 fails when linking because g++ is trying to look for libraries under 3.3.4 instead of 3.3.5. Here's the last little bit of the jpeg-6b emerge where it fails:

g++ -shared -nostdlib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/crtbeginS.o  .libs/jcapimin.o .libs/jcapistd.o .libs/jctrans.o .libs/jcparam.o .libs/jdatadst.o .libs/jcinit.o .libs/jcmaster.o .libs/jcmarker.o .libs/jcmainct.o .libs/jcprepct.o .libs/jccoefct.o .libs/jccolor.o .libs/jcsample.o .libs/jchuff.o .libs/jcphuff.o .libs/jcdctmgr.o .libs/jfdctfst.o .libs/jfdctflt.o .libs/jfdctint.o .libs/jdapimin.o .libs/jdapistd.o .libs/jdtrans.o .libs/jdatasrc.o .libs/jdmaster.o .libs/jdinput.o .libs/jdmarker.o .libs/jdhuff.o .libs/jdphuff.o .libs/jdmainct.o .libs/jdcoefct.o .libs/jdpostct.o .libs/jddctmgr.o .libs/jidctfst.o .libs/jidctflt.o .libs/jidctint.o .libs/jidctred.o .libs/jdsample.o .libs/jdcolor.o .libs/jquant1.o .libs/jquant2.o .libs/jdmerge.o .libs/jcomapi.o .libs/jutils.o .libs/jerror.o .libs/jmemmgr.o .libs/jmemnobs.o  -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/crtendS.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../crtn.o  -Wl,-soname -Wl, -o .libs/
g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../crti.o: No such file or directory
g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/crtbeginS.o: No such file or directory
g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/crtendS.o: No such file or directory
g++: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../crtn.o: No such file or directory

If I run ebuild ./jpeg-6b-r4.ebuild unpack then cd to /var/tmp/portage/jpeg-6b-r4/work/jpeg-6b, run configure (as taken from the output when it was emerged) and then make with the CFLAGS & CXXFLAGS used it works fine. But since jpeg-6b uses the above eclasses when it builds it somehow gets /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4  as a path for linking.

To work around it replaced the following:
    emake \
        CC="$(tc-getCC)" \
        AR="$(tc-getAR) rc" \
        AR2="$(tc-getRANLIB)" \
        || die "make failed"

    emake || die "make failed"

And the emerge worked.

Reproducible: Always
Steps to Reproduce:

Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5,
glibc-, 2.6.10-gentoo-r6 i686)
System uname: 2.6.10-gentoo-r6 i686 Pentium III (Coppermine)
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  7 2005, 20:31:51)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/libtool:   1.5.10-r4
CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -funroll-loops -pipe
-mfpmath=sse -msse -mmmx"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -funroll-loops -pipe
-mfpmath=sse -msse -mmmx"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
USE="x86 apache2 apm arts avi berkdb bitmap-fonts crypt cups curl dba encode f77
fam font-server foomaticdb fortran gd gdbm gif gpm gtk2 hardened imap imlib ipv6
jpeg ldap libg++ libwww mad maildir mikmod mmx motif mpeg mysql ncurses nls nptl
objc oggvorbis opengl oss pam pcap pcre pdflib perl png posix postgres python
quicktime quotas readline sasl sasl2 sdl snmp spell sse ssl svga tcpd tcsh
truetype truetype-fonts type1-fonts xml xml2 xv zlib"
Comment 1 SpanKY gentoo-dev 2005-02-10 15:27:34 UTC
re-emerge libtool

*** This bug has been marked as a duplicate of 80424 ***
Comment 2 SpanKY gentoo-dev 2005-03-29 15:37:08 UTC
*** Bug 87105 has been marked as a duplicate of this bug. ***
Comment 3 Ulf 2005-03-30 00:26:05 UTC
The scheme to solve the problem (at least for me) has been described in

In my case it wasn't neccessary to touch /etc/env.d/05gcc since it was o.k.
Reemerging libtool seems to be the key to solve the problem.

However, in case doing this won't do the trick for you I need to tell you I did a little more than that:
Before I was directed to this solution I did a brute force grep to find any hard coded "i686-pc-linux-gnu/3.3.4" on my system. So I already found and changed file /usr/X11R6/bin/libtool (well this was the only relevant file grep found so far, but grep didn't finish yet). In this file I changed 4 to 5 'i686-pc-linux-gnu/3.3.4' to 'i686-pc-linux-gnu/3.3.5'. 
However, I'm not sure if this makes any difference since I reemerged libtool later. Just wanted to let anybody know in case reemerging libtool alone and checking the /etc/env.d/05gcc file don't help to solve the problem for you.