Re: question about linking errors
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/
Reply to: