When i merge lcms it fails because of some multiple definitions,seems like some strange gcc parameters that it uses... Reproducible: Always Steps to Reproduce: 1.emerge lcms Actual Results: g++ -shared /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o .libs/_lcms_la-lcms_wrap.o -L/usr/x86_64-pc-linux-gnu/lib -L/usr/x86_64-pc-linux-gnu/bin -L/usr/lib/python2.3/config -L/usr/local/lib/python2.3/config ../src/.libs/liblcms.so -lpython2.3 -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2 -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../.. /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/libstdc++.so -lm -lc -lgcc_s /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtendS.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crtn.o -o .libs/_lcms.so /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.init+0x0): In function `_init': /var/tmp/portage/glibc-2.3.2-r9/work/glibc-2.3.2/buildhere/csu/crti.S:11: multiple definition of `_init' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.init+0x0):/var/tmp/portage/glibc-2.3.2-r9/work/glibc-2.3.2/buildhere/csu/crti.S:11: first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.fini+0x0): In function `_fini': : multiple definition of `_fini' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.fini+0x0): first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o(.data.rel+0x0): multiple definition of `__dso_handle' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o(.data.rel+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [_lcms.la] Error 1 make[2]: Leaving directory `/var/tmp/portage/lcms-1.11.1/work/lcms-1.11/python' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/lcms-1.11.1/work/lcms-1.11/python' make: *** [all-recursive] Error 1 !!! ERROR: media-libs/lcms-1.11.1 failed. !!! Function src_compile, Line 30, Exitcode 2 !!! emake failed Expected Results: guess what? Portage 2.0.49-r18 (default-amd64-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.0-test11-gentoo-r2) ================================================================= System uname: 2.6.0-test11-gentoo-r2 x86_64 4 Gentoo Base System version 1.4.3.12 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O3 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.inode.at/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X aalib alsa amd64 apm arts avi berkdb cdr crypt dvdr encode esd fbcon foomaticdb gdbm gif gpm gtk gtk2 imlib ipv6 javascript jpeg libg++ libwww mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang spell sse ssl tcpd truetype xml2 xmms xv zlib"
is this a gcc-3.3 issue?
or an amd64 issue?
try to clean /var/tmp/portage and emerge again
succeeded?
same results,does not work. I think it's an AMD64 issue,as my other gentoo installation is x86 and gcc3.3 where lcms works. (sorry for some reason i only got mail when you switched to NEEDINFO)
guys, it works fine for me ... the only suggestion I can make is to let me know if cd ${S}; libtoolize -c -f _Before_ the econf line helps your situation at all, as that printout is pretty standard if the version of libtool doesn't properly recognize amd64 -Brad
just thought I'd try to help, libtoolize solves the multiple definition problem, but then lcms complains about needing -fPIC. I'll poke around more later and try to fix the fPIC problem.
tester said it builds fine on his amd64
Well, we've tried it on 3 of our amd64 machines, and the results are curious. It built just fine on one 3200+. The other 3200+ complained about multiple defines, libtoolize fixed that, then it complained about a relock. Possibly a python issue? We're looking into it. Then, tried on the dual 240, libtoolize fixed the multiple defines but then it complained about -fPIC. Strange... We'll try some more things and report back anything we find.
please try lcms-1.12
sorry unable to do so ATM. my sata disk seems kind of broken,i'll try as soon as possible...
so,system is back running,sorry it took me so long. lcms-1.12 is broken too. running libtoolize --force --copy fixes this for me. new ebuild will be attached. the bug is in the python support module of lcms. (or at least appears there) output is: g++ -shared /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o .libs/_lcms_la-lcms_wrap.o -L/usr/x86_64-pc-linux-gnu/lib -L/usr/x86_64-pc-linux-gnu/bin -L/usr/lib/python2.3/config -L/usr/local/lib/python2.3/config ../src/.libs/liblcms.so -lpython2.3 -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2 -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../.. /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/libstdc++.so -lm -lc -lgcc_s /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtendS.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crtn.o -o .libs/_lcms.so /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.init+0x0): In function `_init': /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/csu/crti.S:11: multiple definition of `_init' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.init+0x0):/var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/csu/crti.S:11: first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.fini+0x0): In function `_fini': : multiple definition of `_fini' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.fini+0x0): first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o(.data.rel+0x0): multiple definition of `__dso_handle' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o(.data.rel+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [_lcms.la] Error 1 make[2]: Leaving directory `/home/thomas/src/lcms-1.12/python'
Created attachment 25183 [details] lcms-1.12-r1.ebuild
It fails for me even with the 1.12-r1 ebuild attached to this bug. It seems to have something to do with already having lcms installed because it emerged fine the first time, but now that I need to remerge the same version after upgrading to python 2.3.3 it is failing. unmerging lcms doesn't seem to help either. Portage 2.0.50 (default-amd64-2004.0, gcc-3.3.2, glibc-2.3.3_pre20040117-r0, 2.6.1-gentoo-r1) ================================================================= System uname: 2.6.1-gentoo-r1 x86_64 4 Gentoo Base System version 1.4.3.12 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.ccccom.com ftp://gentoo.ccccom.com http://mirror.tucdemonic.org/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa amd64 apache2 apm avi berkdb cdr crypt cups dvd dvdr encode foomaticdb gdbm gif gphoto2 gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg kde ldap libg++ libwww mad mikmod motif mpeg ncurses nls noreiserfs oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sasl sdl slang slp spell ssl tcpd tetex tiff truetype usb xml2 xmms xv zlib" g++ -shared /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o .libs/_lcms_la-lcms_wrap.o -L/usr/x86_64-pc-linux-gnu/lib -L/usr/x86_64-pc-linux-gnu/bin -L/usr/lib/python2.3/config -L/usr/local/lib/python2.3/config ../src/.libs/liblcms.so -lpython2.3 -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2 -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../.. /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/libstdc++.so -lm -lc -lgcc_s /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtendS.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crtn.o -o .libs/_lcms.so /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.init+0x0): In function `_init': /var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/csu/crti.S:11: multiple definition of `_init' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.init+0x0):/var/tmp/portage/glibc-2.3.3_pre20040117/work/glibc-2.3.2/buildhere/csu/crti.S:11: first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.fini+0x0): In function `_fini': : multiple definition of `_fini' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/../../../crti.o(.fini+0x0): first defined here /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o(.data.rel+0x0): multiple definition of `__dso_handle' /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.2/crtbeginS.o(.data.rel+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [_lcms.la] Error 1 make[2]: Leaving directory `/var/tmp/portage/lcms-1.12/work/lcms-1.12/python' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/lcms-1.12/work/lcms-1.12/python' make: *** [all-recursive] Error 1 !!! ERROR: media-libs/lcms-1.12 failed. !!! Function src_compile, Line 37, Exitcode 2 !!! emake failed
libtool 1.5.2? or older?
[ebuild R ] sys-devel/libtool-1.5.2-r1
ok second try replace the libtoolize --force --copy in the ebuild with autoreconf: einfo "Running autoreconf..." autoreconf || die tell me if it worked
I would rather do something like: libtool -c -f; aclocal; autoconf
Either way, can we do something like below: -- Index: lcms-1.12.ebuild =================================================================== RCS file: /home/cvsroot/gentoo-x86/media-libs/lcms/lcms-1.12.ebuild,v retrieving revision 1.5 diff -u -r1.5 lcms-1.12.ebuild --- lcms-1.12.ebuild 29 Jan 2004 04:41:41 -0000 1.5 +++ lcms-1.12.ebuild 11 Feb 2004 21:13:41 -0000 @@ -2,6 +2,8 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-x86/media-libs/lcms/lcms-1.12.ebuild,v 1.5 2004/01/29 04:41:41 agriffis Exp $ +inherit libtool + DESCRIPTION="A lightweight, speed optimized color management engine" HOMEPAGE="http://www.littlecms.com/" SRC_URI="http://www.littlecms.com/${P}.tar.gz" @@ -18,6 +20,7 @@ IUSE="tiff jpeg zlib python" src_compile() { + elibtoolize econf \ --disable-dependency-tracking \ `use_with jpeg` \
elibtoolize doesn't fix the problem here. (and it whould belong in src_unpack IMO). NAME autoreconf - Update generated configuration files DESCRIPTION Run `autoconf' (and `autoheader', `aclocal', `automake', `autopoint' (formerly `gettextize'), and `libtoolize' where appropriate) repeatedly to remake the GNU Build System files in the DIRECTORIES or the direc- tory trees driven by CONFIGURE-AC (defaulting to `.'). so i think this should produce the most consistent updated build system and should be prefered instead of running the tools themselves.
No, you are missing the point of elibtoolize. It patches the included libtool to work properly with portage, with some other often hit bugs. I am just asking as we are talking about this ebuild, and libtool already, that they can add elibtoolize. As for autoreconf - go for it, but my experience is that it screws things over more often than not.
/me is confused what's the real solution to this problem?
_my_ (no idea if its the real) solution is to run autoreconf (of recent autotools of cause) in src_unpack....
Seems in this case autoreconf is Ok. Please just humor me, and add elibtoolize as well (autoreconf do not run libtoolize, and I would rather we do not touch it if not needed).
for me elibtoolize did not work. autoreconf does run libtoolize see comment #20.
You were saying: -- nosferatu root # grep PWORKDIR /usr/bin/libtool /usr/share/libtool/ltmain.sh /usr/bin/libtool: if test "$PWORKDIR"; then /usr/bin/libtool: S="$PWORKDIR" /usr/share/libtool/ltmain.sh: if test "$PWORKDIR"; then /usr/share/libtool/ltmain.sh: S="$PWORKDIR" nosferatu root # ebuild /usr/portage/media-libs/lcms/lcms-1.12.ebuild clean unpack >>> md5 src_uri ;-) lcms-1.12.tar.gz >>> Unpacking source... >>> Unpacking lcms-1.12.tar.gz to /space/var/tmp/portage/lcms-1.12/work >>> Source unpacked. nosferatu root # cd /space/var/tmp/portage/lcms-1.12/work/lcms-1.12/ nosferatu lcms-1.12 # grep PWORKDIR libtool ltmain.sh grep: libtool: No such file or directory nosferatu lcms-1.12 # autoreconf nosferatu lcms-1.12 # grep PWORKDIR libtool ltmain.sh grep: libtool: No such file or directory nosferatu lcms-1.12 # -- Please note the '(where appropriate)' bit. So I guess you did not just run autoreconf ? Or ... ? Btw, since you are so opposed to elibtoolize, did you even check what it is doing, and why I ask for its addition, even though it _will_ NOT fix this specific bug? Did you miss this part in comment #21: I am just asking as we are talking about this ebuild, and libtool already, that they can add elibtoolize. ??
this works for me: src_unpack() { unpack ${A} # fix build on amd64 cd ${S} einfo "Running autoreconf..." autoreconf einfo "Running libtoolize..." elibtoolize }
ok, added autoreconf and elibtoolize
