egcs 1.1.1: apparently multiple library inclusion??

egcs 1.1.1: apparently multiple library inclusion??

[Lorens Kockum]

Hi, I just installed egcs for evaluation, and I have a bit of a
problem during linking.

At first, compiling my existing C and C++ code, no problems.
Then I spent two days adding in STL lists, compiling the object
files as I went, with (finally, at least ;-)) no errors.  (No, I
did not forget the make clean...)

The first errors that come out of the linker are:
% ./display_npl.o: In function `int lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed char const *, signed char const *)':
% /usr/include/g++-2/stl_algobase.h(.text+0x0): multiple definition of `operator new(unsigned int, void *)'
% ./main.o(.text+0x0):/usr/include/g++-2/stl_algobase.h: first defined here
% ./display_npl.o: In function `operator new [](unsigned int, void *)':
% /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/include/new:43: multiple definition of `operator new [](unsigned int, void *)'
% ./main.o:/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/include/new:43: first defined here
% ./display_npl.o: In function `ios::init(streambuf *, ostream *)':
% /usr/include/g++-2/streambuf.h:469: multiple definition of `ios::init(streambuf *, ostream *)'
% ./main.o:/usr/include/g++-2/streambuf.h:469: first defined here

I don't get it.  Does this mean that the offending definitions,
the ones that can not be made multiple times, are made and
included in each object file?

How do I correct that?


FWIW, the errors get even funnier; using a different machine,
system and egcs installed by a different person, AFAICS
according to the recommendations in the egcs documentation:

	su - sysop
	cd /home/sysop/egcs-compile
	../egcs-untar/configure --prefix=/usr/local/egcs
	make
	make install
	logout
	export PATH=/usr/local/egcs/bin:$PATH
	cd project_sources
        ./configure
	make

I have one definition in a .h that is in the compilation
directories /home/sysop/egcs-compile, which are unreadable
for the user doing the compile, and the other in
/usr/local/egcs/whatever.  I suppose that means that a library
is generated during egcs compilation, and that library is put in
/usr/local/egcs, and that I somehow contrive to include both?

Anyway, if someone could point me in the right direction, I'd be
very happy, I'm going in circles here.  More info upon request.

-- 
#include <std_disclaim.h>                          Lorens Kockum

Please, a word of help (Was: Re: egcs 1.1.1: apparently multiple library inclusion??)

[Lorens Kockum]

Last week on the egcs list I myself wrote:
>
>Hi, I just installed egcs for evaluation, and I have a bit of a
>problem during linking.

No responses, sorry if my question was obscure... or just a
FAQ?  Because if it is a FAQ, I certainly didn't find in the
egcs.cygnus.com FAQ.

I'm ready to do any testing or reinstalling or whatever, I've
already installed this three times, with another person doing
an independent install on a different machine, but always the
same results.  I'm getting desperate, I don't want to rewrite
all those things that were so easy to write using the STLs.

My feeling is that is I could manage to get these obscure errors
every time, someone must have come across them before...

Anyone?

>At first, compiling my existing C and C++ code, no problems.
>Then I spent two days adding in STL lists, compiling the object
>files as I went, with (finally, at least ;-)) no errors.  (No, I
>did not forget the make clean...)
>
>The first errors that come out of the linker are:
>% ./display_npl.o: In function `int lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed
>char const *, signed char const *)':
>% /usr/include/g++-2/stl_algobase.h(.text+0x0): multiple definition of `operator new(unsigned int, void *)'
>% ./main.o(.text+0x0):/usr/include/g++-2/stl_algobase.h: first defined here
>% ./display_npl.o: In function `operator new [](unsigned int, void *)':
>% /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/include/new:43: multiple definition of `operator new [](unsigned int, void *)'
>% ./main.o:/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/include/new:43: first defined here
>% ./display_npl.o: In function `ios::init(streambuf *, ostream *)':
>% /usr/include/g++-2/streambuf.h:469: multiple definition of `ios::init(streambuf *, ostream *)'
>% ./main.o:/usr/include/g++-2/streambuf.h:469: first defined here
>
>I don't get it.  Does this mean that the offending definitions,
>the ones that can not be made multiple times, are made and
>included in each object file?
>
>How do I correct that?
>
>
>FWIW, the errors get even funnier; using a different machine,
>system and egcs installed by a different person, AFAICS
>according to the recommendations in the egcs documentation:
>
>	su - sysop
>	cd /home/sysop/egcs-compile
>	../egcs-untar/configure --prefix=/usr/local/egcs
>	make
>	make install
>	logout
>	export PATH=/usr/local/egcs/bin:$PATH
>	cd project_sources
>        ./configure
>	make
>
>I have one definition in a .h that is in the compilation
>directories /home/sysop/egcs-compile, which are unreadable
>for the user doing the compile, and the other in
>/usr/local/egcs/whatever.  I suppose that means that a library
>is generated during egcs compilation, and that library is put in
>/usr/local/egcs, and that I somehow contrive to include both?
>
>Anyway, if someone could point me in the right direction, I'd be
>very happy, I'm going in circles here.  More info upon request.

-- 
#include <std_disclaim.h>                          Lorens Kockum

Re: Please, a word of help (Was: Re: egcs 1.1.1: apparently multiple library inclusion??)

[Chip Salzenberg]

According to Lorens Kockum:
> >At first, compiling my existing C and C++ code, no problems.
> >Then I spent two days adding in STL lists, compiling the object
> >files as I went, with (finally, at least ;-)) no errors.  (No, I
> >did not forget the make clean...)
> >
> >The first errors that come out of the linker are:
> >% ./display_npl.o: In function `int lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed
> >char const *, signed char const *)':
> >% /usr/include/g++-2/stl_algobase.h(.text+0x0): multiple definition of `operator new(unsigned int, void *)'
> >% ./main.o(.text+0x0):/usr/include/g++-2/stl_algobase.h: first defined here

> >I don't get it.  Does this mean that the offending definitions,
> >the ones that can not be made multiple times, are made and
> >included in each object file?

Yes.  Your EGCS apparently believes that it has a GNU linker to depend
on; GNU ld will omit the duplicate definitions.  It may even be a
generic ELF feature, I don't know.
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: Please, a word of help (Was: Re: egcs 1.1.1: apparently multiple library inclusion??)

[Lorens Kockum]

On the egcs list chip@perlsupport.com wrote:
>According to Lorens Kockum:
>
>> >I don't get it.  Does this mean that the offending definitions,
>> >the ones that can not be made multiple times, are made and
>> >included in each object file?
>
>Yes.  Your EGCS apparently believes that it has a GNU linker to depend
>on; GNU ld will omit the duplicate definitions.  It may even be a
>generic ELF feature, I don't know.

Thanks for the response :-) In fact I tried GNU ld, that's in
the g++ FAQ when you search for templates.  What was really
eating me was that I managed to compile and link my template
examples free-standingly, only getting problems when I started
linking against the main project. I found the real problem late
Thursday, after reversing the whole development process (instead
of adding my template code to the main project I added the main
project to the template code, with re-link after each file I
added).

For the information of those who may come across something
similar, it was a <censored> "#define inline" in an obscure
corner of an often but not always included header file.  Somehow
the "#undefine" had got lost, and the resulting code having
absolutely no problems, just a bigger executable and faster
execution, it isn't surprising it wasn't detected immediately
(after all, when you add features, the executable tends to
get bigger, and when you optimize code, you don't mind faster
execution...).  No regression test in the world was going to
catch that one.  Definitely not recommended for templates,
though.

So, not EGCS's fault, documentation or otherwise.  Lost a good
working week, bletcher, bletcher, so back to work now.

HAHappyNewYear everybody.
-- 
#include <std_disclaim.h>                          Lorens Kockum