First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 35442
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Printing Team <printing@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Thomas Weidner <3.14159@gmx.net>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
lcms-1.12.ebuild lcms-1.12-r1.ebuild text/plain Thomas Weidner 2004-02-08 05:56 0000 1.18 KB Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 35442 depends on: Show dependency tree
Bug 35442 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2003-12-09 06:50 0000
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"

------- Comment #1 From Heinrich Wendel (RETIRED) 2003-12-09 08:53:41 0000 -------
is this a gcc-3.3 issue?

------- Comment #2 From Heinrich Wendel (RETIRED) 2003-12-09 10:31:05 0000 -------
or an amd64 issue?

------- Comment #3 From Heinrich Wendel (RETIRED) 2003-12-09 13:21:07 0000 -------
try to clean /var/tmp/portage and emerge again

------- Comment #4 From Heinrich Wendel (RETIRED) 2003-12-13 04:55:53 0000 -------
succeeded?

------- Comment #5 From Thomas Weidner 2003-12-13 10:34:13 0000 -------
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)

------- Comment #6 From Brad House 2003-12-13 10:43:54 0000 -------
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

------- Comment #7 From Darryl Bleau 2003-12-13 22:54:24 0000 -------
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.

------- Comment #8 From Heinrich Wendel (RETIRED) 2003-12-14 11:24:28 0000 -------
tester said it builds fine on his amd64

------- Comment #9 From Darryl Bleau 2003-12-15 13:26:10 0000 -------
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.

------- Comment #10 From Heinrich Wendel (RETIRED) 2003-12-27 13:33:19 0000 -------
please try lcms-1.12

------- Comment #11 From Thomas Weidner 2003-12-28 10:44:23 0000 -------
sorry unable to do so ATM. my sata disk seems kind of broken,i'll try as soon
as possible...

------- Comment #12 From Thomas Weidner 2004-02-08 05:55:20 0000 -------
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'

------- Comment #13 From Thomas Weidner 2004-02-08 05:56:19 0000 -------
Created an attachment (id=25183) [edit]
lcms-1.12-r1.ebuild

------- Comment #14 From Jason Toffaletti 2004-02-08 10:51:47 0000 -------
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

------- Comment #15 From Thomas Weidner 2004-02-08 12:01:42 0000 -------
libtool 1.5.2? or older?

------- Comment #16 From Jason Toffaletti 2004-02-10 13:14:23 0000 -------
[ebuild   R   ] sys-devel/libtool-1.5.2-r1

------- Comment #17 From Thomas Weidner 2004-02-11 06:14:25 0000 -------
ok second try replace the libtoolize --force --copy in the ebuild with
autoreconf:
einfo "Running autoreconf..."
autoreconf || die

tell me if it worked

------- Comment #18 From Martin Schlemmer (RETIRED) 2004-02-11 13:02:14 0000 -------
I would rather do something like:

 libtool -c -f; aclocal; autoconf


------- Comment #19 From Martin Schlemmer (RETIRED) 2004-02-11 13:13:54 0000 -------
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` \

------- Comment #20 From Thomas Weidner 2004-02-12 06:45:47 0000 -------
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.

------- Comment #21 From Martin Schlemmer (RETIRED) 2004-02-12 10:12:14 0000 -------
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.

------- Comment #22 From Heinrich Wendel (RETIRED) 2004-02-16 03:14:07 0000 -------
/me is confused

what's the real solution to this problem?

------- Comment #23 From Thomas Weidner 2004-02-16 06:01:18 0000 -------
_my_ (no idea if its the real) solution is to run autoreconf (of recent
autotools of cause) in src_unpack....

------- Comment #24 From Martin Schlemmer (RETIRED) 2004-02-18 11:09:19 0000 -------
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).

------- Comment #25 From Thomas Weidner 2004-02-18 11:23:39 0000 -------
for me elibtoolize did not work. 
autoreconf does run libtoolize see comment #20.

------- Comment #26 From Martin Schlemmer (RETIRED) 2004-02-18 12:21:36 0000 -------
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.

??



------- Comment #27 From Jason Toffaletti 2004-02-18 23:39:03 0000 -------
this works for me:

src_unpack() {
    unpack ${A}
    # fix build on amd64
    cd ${S}
    einfo "Running autoreconf..."
    autoreconf
    einfo "Running libtoolize..."
    elibtoolize
}

------- Comment #28 From Heinrich Wendel (RETIRED) 2004-02-21 03:58:34 0000 -------
ok, added autoreconf and elibtoolize

First Last Prev Next    No search results available      Search page      Enter new bug