I'd say it is the locally built gcc. Why not use the prebuilt one? On Tue, May 17, 2005 at 06:52:52PM +1000, Jim Watson wrote: > While linking berkeleydb in openoffice.org on linux sparc i get multiple > errors such as below[0]. > > So I am wondering if this is a bug with binutils packaging, or is it a > problem with > my own complied version of gcc, or is it something wrong in the compiled code > which explicitly is linking in those duplicated files? I know the errors > stop if i stop it linking in those files, but I wonder is that the correct > solution because of the path names reported (from the packagers build > system?) > > If i go to /usr/lib and grep -r "/build/buildd" * there are very many binary > files this path embedded somewhere. > > thanks > > jim > > [0] > <snip> > -L/usr/lib/../lib /usr/local/lib/../lib/libstdc++.so -lm -lc -lgcc_s_32 > /usr/local/lib/gcc/sparc64-unknown-linux-gnu/3.4.3/32/crtendS.o / > usr/lib/../lib/crtn.o -m32 -o .libs/libdb_cxx-4.2.so > /usr/lib/../lib/crti.o(.init+0x0): In function init': > /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S:9: multiple > defin > ition of init' > /usr/lib/../lib/crti.o(.init+0x0):/build/buildd/glibc-2.3.2.ds1/build-tree/sparc > -libc/csu/crti.S:9: first defined here > /usr/bin/ld: Disabling relaxation: it will not work with multiple > definitions > /usr/lib/../lib/crti.o(.fini+0x0): In function fini': > : multiple definition of fini' > /usr/lib/../lib/crti.o(.fini+0x0): first defined here > /usr/local/lib/gcc/sparc64-unknown-linux-gnu/3.4.3/32/crtbeginS.o(.data.rel+0x0) > : multiple definition of _dso_handle' > /usr/local/lib/gcc/sparc64-unknown-linux-gnu/3.4.3/32/crtbeginS.o(.data.rel+0x0) > : first defined here > collect2: ld returned 1 exit status >
-- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/