multiple definitions of 'xxx keyed to...' in egcs-1.1.1

multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

Platform: linux S.u.S.E. 5.3, egcs 1.1.1

I'm getting messages of the following type:
	.obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)':
	/home/sb/apps/include/g++/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)'
	.obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++/stl_list.h:304: first defined here
	collect2: ld returned 1 exit status
when linking some (not all) of my shared libraries.

I can't remember having seen any of these with egcs 1.0.3.  

Searches on Alta Vista for this problem found no meaningful responses,
searches on Deja News for "egcs & multiple & definition & keyed" gave
me two persons with the same problem on linux, in october last year
(and one "article unavailable"), but no responses.

I got a response from one of the two today, and he lost the problem by 
rewriting all of the code that used STL.  Then the problem
mysteriously went away.

Not a good sign...

I'll isolate a test case if I can.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
> I'm getting messages of the following type:
> 	.obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)':
> 	/home/sb/apps/include/g++/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)'
> 	.obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++/stl_list.h:304: first defined here
> 	collect2: ld returned 1 exit status
> when linking some (not all) of my shared libraries.

> I can't remember having seen any of these with egcs 1.0.3.  

> Searches on Alta Vista for this problem found no meaningful responses,
> searches on Deja News for "egcs & multiple & definition & keyed" gave
> me two persons with the same problem on linux, in october last year
> (and one "article unavailable"), but no responses.

Hm... it suddenly struck me that I've been running with
--enable-shared, and that this is not a default option, *and* that it
affects linking.

I'm now doing a brand new "make bootstrap" of egcs-1.1.1 (for the
second time, the first crashed in the installation phase for
libiberty.a and didn't install essential parts of the compiler
(eg. cc1plus).  So I cleaned away everything and am doing a brand new
bootstrap).

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
>> I'm getting messages of the following type:
>> .obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)':
>> /home/sb/apps/include/g++/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)'
>> .obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++/stl_list.h:304: first defined here
>> collect2: ld returned 1 exit status
>> when linking some (not all) of my shared libraries.

>> I can't remember having seen any of these with egcs 1.0.3.  

[snip!]

> Hm... it suddenly struck me that I've been running with
> --enable-shared, and that this is not a default option, *and* that it
> affects linking.

I unpacked 1.1.1, configured without --enable-shared, compiled with
"make bootstrap", and installed it.

I still get the exact same error messages when linking some of my
shared libs.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Steinar Bang <sb@metis.no>:
> 
> >>>>> Steinar Bang <sb@metis.no>:
> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1

When you use Linux, it is always a good idea to try my egcs for Linux.
You can find it in the egcs list archive.


H.J.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1

> When you use Linux, it is always a good idea to try my egcs for Linux.
> You can find it in the egcs list archive.

Thanx for the tip.  Umm... you wouldn't have a more specific location
of your egcs variant (eg. which list?  And when?), since the list
archives lack a search mechanism?

What kind of changes have you done?

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> hjl@lucon.org (H.J. Lu):
> 
> >> 
> >> >>>>> Steinar Bang <sb@metis.no>:
> >> 
> >> >>>>> Steinar Bang <sb@metis.no>:
> >> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
> 
> > When you use Linux, it is always a good idea to try my egcs for Linux.
> > You can find it in the egcs list archive.
> 
> Thanx for the tip.  Umm... you wouldn't have a more specific location
> of your egcs variant (eg. which list?  And when?), since the list
> archives lack a search mechanism?

The egcs mailing list. You can find it at

http://egcs.cygnus.com

I posted it in Jan. 1999. You can sort it by author.

> 
> What kind of changes have you done?
> 

Get it and read the release note as well as ChangeLogs. It may solve
your problem. You also need binutils 2.9.1.0.19a or above.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> Thanx for the tip.  Umm... you wouldn't have a more specific location
>> of your egcs variant (eg. which list?  And when?), since the list
>> archives lack a search mechanism?

> The egcs mailing list. You can find it at

>	http://egcs.cygnus.com

I know.  More specifically at
	http://egcs.cygnus.com/lists.html

But there's egcs-announce, egcs, egcs-bugs, egcs-patches, egcs-cvs,
and egcs-testsresults.  Some more likely than others, granted.  But
many of them high volume and with fairly large indexes.

Please note: I'm not critisizing the web maintainer or anyone.  I'm
just making a statement to the fact that a list archive search
mechanism would have been useful.

> I posted it in Jan. 1999.

Thanx again.  I'm assuming we're talking about the main egcs list.

> You can sort it by author.

I know.

Lesse... 
	http://www.cygnus.com/ml/egcs/1999-Jan/0712.html
(to save others the work)

>> What kind of changes have you done?

> Get it and read the release note as well as ChangeLogs.

I got the patches at 
	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
and applied them to a freshly unpacked egcs-1.1.1, but they didn't
change the ChangeLog as far as I could tell.

Is
	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/release.egcs-1.1.1
the release notes?

> It may solve your problem.

Hopefully.  The problem seems to be pretty obscure, judging from the
low number of hits I got from Deja News and Alta Vista, but I'm
guessing that it's real enough from the fact that I got hits on people 
with similar problems at all.

Have you seen similar behaviour?

> You also need binutils 2.9.1.0.19a or above.

OK.  I have no idea where alphas of binutils can be found.  You
wouldn't happen to have a pointer?

Thanx!


- Steinar

problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> hjl@lucon.org (H.J. Lu):
>> Get it and read the release note as well as ChangeLogs.

> I got the patches at 
> 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
> and applied them to a freshly unpacked egcs-1.1.1, but they didn't
> change the ChangeLog as far as I could tell.

I've problems configuring the patched egcs-1.1.1:
	/home/sb/src/install/egcs-1.1.1 > ./configure --prefix=/home/sb/apps
	Configuring for a i686-pc-linux-gnulibc1 host.
	./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory

Re: problem building linux specific 1.1.1

[H.J. Lu]

> 
> >>>>> Steinar Bang <sb@metis.no>:
> 
> >>>>> hjl@lucon.org (H.J. Lu):
> >> Get it and read the release note as well as ChangeLogs.
> 
> > I got the patches at 
> > 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
> > and applied them to a freshly unpacked egcs-1.1.1, but they didn't
> > change the ChangeLog as far as I could tell.

Please check ChangeLog.linux.

> 
> I've problems configuring the patched egcs-1.1.1:
> 	/home/sb/src/install/egcs-1.1.1 > ./configure --prefix=/home/sb/apps
> 	Configuring for a i686-pc-linux-gnulibc1 host.
> 	./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory
> 

You didn't apply the patch right. config.if should be there. I see it
in my patch. Please tell me exactly how you unpack egcs 1.1.1 and apply
my patch.

-- 
H.J. Lu (hjl@gnu.org)

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> > I got the patches at 
>> > 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
>> > and applied them to a freshly unpacked egcs-1.1.1, but they didn't
>> > change the ChangeLog as far as I could tell.

> Please check ChangeLog.linux.

There isn't one.

>> 
>> I've problems configuring the patched egcs-1.1.1:
>> /home/sb/src/install/egcs-1.1.1 > ./configure --prefix=/home/sb/apps
>> Configuring for a i686-pc-linux-gnulibc1 host.
>> ./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory
>> 

> You didn't apply the patch right. config.if should be there. I see it
> in my patch. Please tell me exactly how you unpack egcs 1.1.1 and apply
> my patch.

/home/sb/src/install% zcat ~/src/distrib/egcs-1.1.1.tar.gz | tar xf -
/home/sb/src/install% zcat ~/src/distrib/egcs-1.1.1-19990115-linux.diff.gz | patch 
[lots of hunk# succeeded snipped]

/home/sb/src/install% cd egcs-1.1.1/
/home/sb/src/install/egcs-1.1.1% ./configure --prefix=/home/sb/apps
Configuring for a i686-pc-linux-gnulibc1 host.
./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory

Since I'm missing some files, there's probably a command line argument 
to patch that will tell it to create files, lesse... (M-x man patch RET)
no there wasn't... arrrrgh!  Lots of files are created on the
directory above the egcs-1.1.1 directory... @$&@!!  When I saw
"succeed" in the patch messages flickering over the screen I assumed
that the directory information in the patch was correct.

Hmph... moving down into the egcs-1.1.1 directory to apply the patch
applied the missing patches (the ones containing the missing files?),
but seems to croak on something else:
Patching file Makefile.in using Plan A...
Hunk #1 failed at 344.
Hunk #2 failed at 801.
Hunk #3 failed at 823.
Hunk #4 failed at 2189.
Hunk #5 failed at 2338.
Hunk #6 failed at 2819.
Hunk #7 failed at 2844.
Hunk #8 failed at 2869.
Hunk #9 failed at 2894.
Hunk #10 succeeded at 2978 with fuzz 2 (offset -1 lines).
patch: **** misordered hunks! output would be garbled

If I moved up one level to apply the patch, I got asked about some
presumably reversed patches and if they should be applied (to which I
said no to everything) and got a log slightly larger than the first
time I did this.

Hm... I could try some -p magic, but the diffs in this patch seems to
have different directory levels... I'll live with the two applications 
of the patch for now, I think... at least it configured this time.

I'm starting to get pretty tired of unpacking and patching by now.

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> If I moved up one level to apply the patch, I got asked about some
> presumably reversed patches and if they should be applied (to which I
> said no to everything) and got a log slightly larger than the first
> time I did this.

> Hm... I could try some -p magic, but the diffs in this patch seems to
> have different directory levels... I'll live with the two applications 
> of the patch for now, I think... at least it configured this time.

> I'm starting to get pretty tired of unpacking and patching by now.

It configured, but didn't build.  "make bootstrap" ended up here:
...
make[3]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo/makeinfo'
make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
Bootstrapping the compiler
make[1]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
make CC="gcc" libdir=/home/sb/apps/lib LANGUAGES="c "
make[2]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
cd . && autoheader
/bin/sh: autoheader: command not found
make[2]: *** [cstamp-h.in] Error 127
make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
make: *** [bootstrap] Error 2

Does anybody have an idea of what "autoheader" is?

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>> If I moved up one level to apply the patch, I got asked about some
>> presumably reversed patches and if they should be applied (to which I
>> said no to everything) and got a log slightly larger than the first
>> time I did this.

>> Hm... I could try some -p magic, but the diffs in this patch seems to
>> have different directory levels... I'll live with the two applications 
>> of the patch for now, I think... at least it configured this time.

Thanx to Martin Kahlert <martin.kahlert@mchp.siemens.de> who told me
to use the "-p1 -E" arguments to patch.  That took care of the
directory problems.

However I'm still getting the problem of the missing "autoheader"
program (on S.u.S.E. 5.3).  Hm... do I need "autoconf" and "GNU m4"
installed on the system...?  Some Deja News messages seems to
indicate this.

Hm... should ./configure have searched for autoheader and compensated
for a missing autoheader?

> It configured, but didn't build.  "make bootstrap" ended up here:
> ...
> make[3]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo/makeinfo'
> make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
> make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
> Bootstrapping the compiler
> make[1]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
> make CC="gcc" libdir=/home/sb/apps/lib LANGUAGES="c "
> make[2]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
> cd . && autoheader
> /bin/sh: autoheader: command not found
> make[2]: *** [cstamp-h.in] Error 127
> make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
> make[1]: *** [bootstrap] Error 2
> make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
> make: *** [bootstrap] Error 2

> Does anybody have an idea of what "autoheader" is?

Re: problem building linux specific 1.1.1

[Andreas Schwab]

Steinar Bang <sb@metis.no> writes:

|> >>>>> Steinar Bang <sb@metis.no>:
|> 
|> >>>>> Steinar Bang <sb@metis.no>:
|> >> If I moved up one level to apply the patch, I got asked about some
|> >> presumably reversed patches and if they should be applied (to which I
|> >> said no to everything) and got a log slightly larger than the first
|> >> time I did this.
|> 
|> >> Hm... I could try some -p magic, but the diffs in this patch seems to
|> >> have different directory levels... I'll live with the two applications 
|> >> of the patch for now, I think... at least it configured this time.
|> 
|> Thanx to Martin Kahlert <martin.kahlert@mchp.siemens.de> who told me
|> to use the "-p1 -E" arguments to patch.  That took care of the
|> directory problems.
|> 
|> However I'm still getting the problem of the missing "autoheader"
|> program (on S.u.S.E. 5.3).  Hm... do I need "autoconf" and "GNU m4"
|> installed on the system...?  Some Deja News messages seems to
|> indicate this.

You only need them if you upgrade via a patch, otherwise the timestamps
will be correct.  Btw, if you use the latest version of patch (2.5) you
can use `patch -p1 -T', which causes patch to set the timestamp from the
diff headers.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>:

>>> However I'm still getting the problem of the missing "autoheader"
>>> program (on S.u.S.E. 5.3).  Hm... do I need "autoconf" and "GNU m4"
>>> installed on the system...?  Some Deja News messages seems to
>>> indicate this.

> You only need them if you upgrade via a patch, otherwise the
> timestamps will be correct.  Btw, if you use the latest version of
> patch (2.5) you can use `patch -p1 -T', which causes patch to set
> the timestamp from the diff headers.

Hm... I have patch 2.1 it seems.  At least that's what "patch -v"
reports. 

In any case, I installed the autoconf package from the S.u.S.E. 5.3
distribution, available from eg.
	http://rufus.w3.org/linux/RPM/suse/5.3/d1/autoconf-2.12-13.i386.html
or on the CD.

Now "make boostrap" seems to run OK.

Thanx!

(then it only remains to see if it fixes my shared lib linking problem 
without the binutils alpha which I din't know where to find (or even
*with* it, for that matter)) 

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>:

>>> However I'm still getting the problem of the missing "autoheader"
>>> program (on S.u.S.E. 5.3).  Hm... do I need "autoconf" and "GNU m4"
>>> installed on the system...?  Some Deja News messages seems to
>>> indicate this.

> You only need them if you upgrade via a patch, otherwise the
> timestamps will be correct.  Btw, if you use the latest version of
> patch (2.5) you can use `patch -p1 -T', which causes patch to set
> the timestamp from the diff headers.

Hm... I have patch 2.1 it seems.  At least that's what "patch -v"
reports. 

In any case, I installed the autoconf package from the S.u.S.E. 5.3
distribution, available from eg.
	http://rufus.w3.org/linux/RPM/suse/5.3/d1/autoconf-2.12-13.i386.html
or on the CD.

Now "make boostrap" seems to run OK.

Thanx!

(then it only remains to see if it fixes my shared lib linking problem 
without the binutils alpha which I din't know where to find (or even
*with* it, for that matter)) 

Re: problem building linux specific 1.1.1

[Andreas Schwab]

Steinar Bang <sb@metis.no> writes:

|> >>>>> Steinar Bang <sb@metis.no>:
|> 
|> >>>>> Steinar Bang <sb@metis.no>:
|> >> If I moved up one level to apply the patch, I got asked about some
|> >> presumably reversed patches and if they should be applied (to which I
|> >> said no to everything) and got a log slightly larger than the first
|> >> time I did this.
|> 
|> >> Hm... I could try some -p magic, but the diffs in this patch seems to
|> >> have different directory levels... I'll live with the two applications 
|> >> of the patch for now, I think... at least it configured this time.
|> 
|> Thanx to Martin Kahlert <martin.kahlert@mchp.siemens.de> who told me
|> to use the "-p1 -E" arguments to patch.  That took care of the
|> directory problems.
|> 
|> However I'm still getting the problem of the missing "autoheader"
|> program (on S.u.S.E. 5.3).  Hm... do I need "autoconf" and "GNU m4"
|> installed on the system...?  Some Deja News messages seems to
|> indicate this.

You only need them if you upgrade via a patch, otherwise the timestamps
will be correct.  Btw, if you use the latest version of patch (2.5) you
can use `patch -p1 -T', which causes patch to set the timestamp from the
diff headers.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>> If I moved up one level to apply the patch, I got asked about some
>> presumably reversed patches and if they should be applied (to which I
>> said no to everything) and got a log slightly larger than the first
>> time I did this.

>> Hm... I could try some -p magic, but the diffs in this patch seems to
>> have different directory levels... I'll live with the two applications 
>> of the patch for now, I think... at least it configured this time.

Thanx to Martin Kahlert <martin.kahlert@mchp.siemens.de> who told me
to use the "-p1 -E" arguments to patch.  That took care of the
directory problems.

However I'm still getting the problem of the missing "autoheader"
program (on S.u.S.E. 5.3).  Hm... do I need "autoconf" and "GNU m4"
installed on the system...?  Some Deja News messages seems to
indicate this.

Hm... should ./configure have searched for autoheader and compensated
for a missing autoheader?

> It configured, but didn't build.  "make bootstrap" ended up here:
> ...
> make[3]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo/makeinfo'
> make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
> make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
> Bootstrapping the compiler
> make[1]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
> make CC="gcc" libdir=/home/sb/apps/lib LANGUAGES="c "
> make[2]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
> cd . && autoheader
> /bin/sh: autoheader: command not found
> make[2]: *** [cstamp-h.in] Error 127
> make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
> make[1]: *** [bootstrap] Error 2
> make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
> make: *** [bootstrap] Error 2

> Does anybody have an idea of what "autoheader" is?

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> If I moved up one level to apply the patch, I got asked about some
> presumably reversed patches and if they should be applied (to which I
> said no to everything) and got a log slightly larger than the first
> time I did this.

> Hm... I could try some -p magic, but the diffs in this patch seems to
> have different directory levels... I'll live with the two applications 
> of the patch for now, I think... at least it configured this time.

> I'm starting to get pretty tired of unpacking and patching by now.

It configured, but didn't build.  "make bootstrap" ended up here:
...
make[3]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo/makeinfo'
make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/texinfo'
Bootstrapping the compiler
make[1]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
make CC="gcc" libdir=/home/sb/apps/lib LANGUAGES="c "
make[2]: Entering directory `/home/sb/src/install/egcs-1.1.1/gcc'
cd . && autoheader
/bin/sh: autoheader: command not found
make[2]: *** [cstamp-h.in] Error 127
make[2]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/home/sb/src/install/egcs-1.1.1/gcc'
make: *** [bootstrap] Error 2

Does anybody have an idea of what "autoheader" is?

Re: problem building linux specific 1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> > I got the patches at 
>> > 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
>> > and applied them to a freshly unpacked egcs-1.1.1, but they didn't
>> > change the ChangeLog as far as I could tell.

> Please check ChangeLog.linux.

There isn't one.

>> 
>> I've problems configuring the patched egcs-1.1.1:
>> /home/sb/src/install/egcs-1.1.1 > ./configure --prefix=/home/sb/apps
>> Configuring for a i686-pc-linux-gnulibc1 host.
>> ./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory
>> 

> You didn't apply the patch right. config.if should be there. I see it
> in my patch. Please tell me exactly how you unpack egcs 1.1.1 and apply
> my patch.

/home/sb/src/install% zcat ~/src/distrib/egcs-1.1.1.tar.gz | tar xf -
/home/sb/src/install% zcat ~/src/distrib/egcs-1.1.1-19990115-linux.diff.gz | patch 
[lots of hunk# succeeded snipped]

/home/sb/src/install% cd egcs-1.1.1/
/home/sb/src/install/egcs-1.1.1% ./configure --prefix=/home/sb/apps
Configuring for a i686-pc-linux-gnulibc1 host.
./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory

Since I'm missing some files, there's probably a command line argument 
to patch that will tell it to create files, lesse... (M-x man patch RET)
no there wasn't... arrrrgh!  Lots of files are created on the
directory above the egcs-1.1.1 directory... @$&@!!  When I saw
"succeed" in the patch messages flickering over the screen I assumed
that the directory information in the patch was correct.

Hmph... moving down into the egcs-1.1.1 directory to apply the patch
applied the missing patches (the ones containing the missing files?),
but seems to croak on something else:
Patching file Makefile.in using Plan A...
Hunk #1 failed at 344.
Hunk #2 failed at 801.
Hunk #3 failed at 823.
Hunk #4 failed at 2189.
Hunk #5 failed at 2338.
Hunk #6 failed at 2819.
Hunk #7 failed at 2844.
Hunk #8 failed at 2869.
Hunk #9 failed at 2894.
Hunk #10 succeeded at 2978 with fuzz 2 (offset -1 lines).
patch: **** misordered hunks! output would be garbled

If I moved up one level to apply the patch, I got asked about some
presumably reversed patches and if they should be applied (to which I
said no to everything) and got a log slightly larger than the first
time I did this.

Hm... I could try some -p magic, but the diffs in this patch seems to
have different directory levels... I'll live with the two applications 
of the patch for now, I think... at least it configured this time.

I'm starting to get pretty tired of unpacking and patching by now.

Re: problem building linux specific 1.1.1

[H.J. Lu]

> 
> >>>>> Steinar Bang <sb@metis.no>:
> 
> >>>>> hjl@lucon.org (H.J. Lu):
> >> Get it and read the release note as well as ChangeLogs.
> 
> > I got the patches at 
> > 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
> > and applied them to a freshly unpacked egcs-1.1.1, but they didn't
> > change the ChangeLog as far as I could tell.

Please check ChangeLog.linux.

> 
> I've problems configuring the patched egcs-1.1.1:
> 	/home/sb/src/install/egcs-1.1.1 > ./configure --prefix=/home/sb/apps
> 	Configuring for a i686-pc-linux-gnulibc1 host.
> 	./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory
> 

You didn't apply the patch right. config.if should be there. I see it
in my patch. Please tell me exactly how you unpack egcs 1.1.1 and apply
my patch.

-- 
H.J. Lu (hjl@gnu.org)

problem building linux specific 1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> hjl@lucon.org (H.J. Lu):
>> Get it and read the release note as well as ChangeLogs.

> I got the patches at 
> 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
> and applied them to a freshly unpacked egcs-1.1.1, but they didn't
> change the ChangeLog as far as I could tell.

I've problems configuring the patched egcs-1.1.1:
	/home/sb/src/install/egcs-1.1.1 > ./configure --prefix=/home/sb/apps
	Configuring for a i686-pc-linux-gnulibc1 host.
	./configure: /home/sb/src/install/egcs-1.1.1/config.if: No such file or directory

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > The egcs mailing list. You can find it at
> 
> >	http://egcs.cygnus.com
> 
> I know.  More specifically at
> 	http://egcs.cygnus.com/lists.html
> 
> But there's egcs-announce, egcs, egcs-bugs, egcs-patches, egcs-cvs,
> and egcs-testsresults.  Some more likely than others, granted.  But
> many of them high volume and with fairly large indexes.

I said "the egcs mailing list.", not "the egcs-patches mailing list."

> 
> Is
> 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/release.egcs-1.1.1
> the release notes?

Yes.

> 
> Have you seen similar behaviour?

I seem to remember a similar problem in libc 5 before I switched
to glibc 2.

> 
> > You also need binutils 2.9.1.0.19a or above.
> 
> OK.  I have no idea where alphas of binutils can be found.  You
> wouldn't happen to have a pointer?
> 

You can find the Linux egcs and binutils at

1. ftp://tsx-11.mit.edu/pub/linux/packages/GCC
2. ftp://sunsite.unc.edu/pub/Linux/GCC

and also

ftp://ftp.yggdrasil.com/private/hjl

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> 
>> > The egcs mailing list. You can find it at
>> 
>> >	http://egcs.cygnus.com
>> 
>> I know.  More specifically at
>>	http://egcs.cygnus.com/lists.html
>> 
>> But there's egcs-announce, egcs, egcs-bugs, egcs-patches, egcs-cvs,
>> and egcs-testsresults.  Some more likely than others, granted.  But
>> many of them high volume and with fairly large indexes.

> I said "the egcs mailing list.", not "the egcs-patches mailing list."

Like I said, some were more likely than others.  But to be unambious
it would be better to word yourself something like this:

 "See my message to the egcs mailing list
	http://www.cygnus.com/ml/egcs/
  in January 1999, with the subject '...'"

or even (if you felt in a exceptionally good and helpful mood that
day):

 "See my message to the egcs mailing list
	http://www.cygnus.com/ml/egcs/1999-Jan/0712.html
  for egcs 1.1.1 on linux"

There's this little thing called a URL, that used correctly (ie. to
refer to a specific resource instead of a site containing the
resource(*)) can save authors a lot of time in explanation and readers 
a lot of time in guessing and wandering through web sites.


- Steinar

(*) Side note and off-topic: my major HTML frames nag, is that it
    makes it harder to boomark a particular resource.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> 
>> > The egcs mailing list. You can find it at
>> 
>> >	http://egcs.cygnus.com
>> 
>> I know.  More specifically at
>>	http://egcs.cygnus.com/lists.html
>> 
>> But there's egcs-announce, egcs, egcs-bugs, egcs-patches, egcs-cvs,
>> and egcs-testsresults.  Some more likely than others, granted.  But
>> many of them high volume and with fairly large indexes.

> I said "the egcs mailing list.", not "the egcs-patches mailing list."

Like I said, some were more likely than others.  But to be unambious
it would be better to word yourself something like this:

 "See my message to the egcs mailing list
	http://www.cygnus.com/ml/egcs/
  in January 1999, with the subject '...'"

or even (if you felt in a exceptionally good and helpful mood that
day):

 "See my message to the egcs mailing list
	http://www.cygnus.com/ml/egcs/1999-Jan/0712.html
  for egcs 1.1.1 on linux"

There's this little thing called a URL, that used correctly (ie. to
refer to a specific resource instead of a site containing the
resource(*)) can save authors a lot of time in explanation and readers 
a lot of time in guessing and wandering through web sites.


- Steinar

(*) Side note and off-topic: my major HTML frames nag, is that it
    makes it harder to boomark a particular resource.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > The egcs mailing list. You can find it at
> 
> >	http://egcs.cygnus.com
> 
> I know.  More specifically at
> 	http://egcs.cygnus.com/lists.html
> 
> But there's egcs-announce, egcs, egcs-bugs, egcs-patches, egcs-cvs,
> and egcs-testsresults.  Some more likely than others, granted.  But
> many of them high volume and with fairly large indexes.

I said "the egcs mailing list.", not "the egcs-patches mailing list."

> 
> Is
> 	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/release.egcs-1.1.1
> the release notes?

Yes.

> 
> Have you seen similar behaviour?

I seem to remember a similar problem in libc 5 before I switched
to glibc 2.

> 
> > You also need binutils 2.9.1.0.19a or above.
> 
> OK.  I have no idea where alphas of binutils can be found.  You
> wouldn't happen to have a pointer?
> 

You can find the Linux egcs and binutils at

1. ftp://tsx-11.mit.edu/pub/linux/packages/GCC
2. ftp://sunsite.unc.edu/pub/Linux/GCC

and also

ftp://ftp.yggdrasil.com/private/hjl

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> hjl@lucon.org (H.J. Lu):

[snip! on the egcs-1.1.1 for linux mentioned in
	<URL: http://www.cygnus.com/ml/egcs/1999-Jan/0712.html >]
>> It may solve your problem.

> Hopefully.  The problem seems to be pretty obscure, judging from the
> low number of hits I got from Deja News and Alta Vista, but I'm
> guessing that it's real enough from the fact that I got hits on people 
> with similar problems at all.
[snip!]

>> You also need binutils 2.9.1.0.19a or above.

I've now compiled and installed the patched egcs-1.1.1 (configured
with the command "./configure --prefix=/home/sb/apps", and compiled
and installed binutils 2.9.1.0.19a (from
<URL: ftp://tsx-11.mit.edu/pub/linux/packages/GCC >) with the same
configuration command.

No --enable-shared this time.

I still see the same problem when linking some of the shared libs,
even after I've done a "make clean" and a fresh make on the entire
project.

An excerpt from a typical error message is attached for someone who
just stumbled onto this message.


- Steinar

Typical error message when linking a shared lib:

.obj/debug/myprint.o: In function `myPrint type_info function':
/home/sb/2x/src/gem/examples/myprint.cpp(.text+0x4): multiple definition of `global destructors keyed to rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> >, pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue>, select1st<pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > >, __default_alloc_template<0, 0> >::insert_unique(pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> const &)'
.obj/debug/hellodialog.o(.text+0x4):/home/sb/2x/src/gem/examples/hellodialog.cpp: first defined here
.obj/debug/myprint.o: In function `global constructors keyed to rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> >, pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue>, select1st<pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > >, __default_alloc_template<0, 0> >::global destructors keyed to insert_unique(pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> const &)':
/home/sb/apps/include/g++-2/stl_map.h:138: multiple definition of `global constructors keyed to rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> >, pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue>, select1st<pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > >, __default_alloc_template<0, 0> >::global destructors keyed to insert_unique(pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> const &)'
.obj/debug/hellodialog.o:/home/sb/apps/include/g++-2/stl_map.h:138: first defined here

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> hjl@lucon.org (H.J. Lu):

[snip! on the egcs-1.1.1 for linux mentioned in
	<URL: http://www.cygnus.com/ml/egcs/1999-Jan/0712.html >]
>> It may solve your problem.

> Hopefully.  The problem seems to be pretty obscure, judging from the
> low number of hits I got from Deja News and Alta Vista, but I'm
> guessing that it's real enough from the fact that I got hits on people 
> with similar problems at all.
[snip!]

>> You also need binutils 2.9.1.0.19a or above.

I've now compiled and installed the patched egcs-1.1.1 (configured
with the command "./configure --prefix=/home/sb/apps", and compiled
and installed binutils 2.9.1.0.19a (from
<URL: ftp://tsx-11.mit.edu/pub/linux/packages/GCC >) with the same
configuration command.

No --enable-shared this time.

I still see the same problem when linking some of the shared libs,
even after I've done a "make clean" and a fresh make on the entire
project.

An excerpt from a typical error message is attached for someone who
just stumbled onto this message.


- Steinar

Typical error message when linking a shared lib:

.obj/debug/myprint.o: In function `myPrint type_info function':
/home/sb/2x/src/gem/examples/myprint.cpp(.text+0x4): multiple definition of `global destructors keyed to rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> >, pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue>, select1st<pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > >, __default_alloc_template<0, 0> >::insert_unique(pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> const &)'
.obj/debug/hellodialog.o(.text+0x4):/home/sb/2x/src/gem/examples/hellodialog.cpp: first defined here
.obj/debug/myprint.o: In function `global constructors keyed to rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> >, pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue>, select1st<pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > >, __default_alloc_template<0, 0> >::global destructors keyed to insert_unique(pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> const &)':
/home/sb/apps/include/g++-2/stl_map.h:138: multiple definition of `global constructors keyed to rb_tree<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> >, pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue>, select1st<pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> >, less<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > >, __default_alloc_template<0, 0> >::global destructors keyed to insert_unique(pair<basic_string<char, string_char_traits<char>, __default_alloc_template<0, 0> > const, KValue> const &)'
.obj/debug/hellodialog.o:/home/sb/apps/include/g++-2/stl_map.h:138: first defined here

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> Thanx for the tip.  Umm... you wouldn't have a more specific location
>> of your egcs variant (eg. which list?  And when?), since the list
>> archives lack a search mechanism?

> The egcs mailing list. You can find it at

>	http://egcs.cygnus.com

I know.  More specifically at
	http://egcs.cygnus.com/lists.html

But there's egcs-announce, egcs, egcs-bugs, egcs-patches, egcs-cvs,
and egcs-testsresults.  Some more likely than others, granted.  But
many of them high volume and with fairly large indexes.

Please note: I'm not critisizing the web maintainer or anyone.  I'm
just making a statement to the fact that a list archive search
mechanism would have been useful.

> I posted it in Jan. 1999.

Thanx again.  I'm assuming we're talking about the main egcs list.

> You can sort it by author.

I know.

Lesse... 
	http://www.cygnus.com/ml/egcs/1999-Jan/0712.html
(to save others the work)

>> What kind of changes have you done?

> Get it and read the release note as well as ChangeLogs.

I got the patches at 
	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
and applied them to a freshly unpacked egcs-1.1.1, but they didn't
change the ChangeLog as far as I could tell.

Is
	ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/release.egcs-1.1.1
the release notes?

> It may solve your problem.

Hopefully.  The problem seems to be pretty obscure, judging from the
low number of hits I got from Deja News and Alta Vista, but I'm
guessing that it's real enough from the fact that I got hits on people 
with similar problems at all.

Have you seen similar behaviour?

> You also need binutils 2.9.1.0.19a or above.

OK.  I have no idea where alphas of binutils can be found.  You
wouldn't happen to have a pointer?

Thanx!


- Steinar

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> hjl@lucon.org (H.J. Lu):
> 
> >> 
> >> >>>>> Steinar Bang <sb@metis.no>:
> >> 
> >> >>>>> Steinar Bang <sb@metis.no>:
> >> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
> 
> > When you use Linux, it is always a good idea to try my egcs for Linux.
> > You can find it in the egcs list archive.
> 
> Thanx for the tip.  Umm... you wouldn't have a more specific location
> of your egcs variant (eg. which list?  And when?), since the list
> archives lack a search mechanism?

The egcs mailing list. You can find it at

http://egcs.cygnus.com

I posted it in Jan. 1999. You can sort it by author.

> 
> What kind of changes have you done?
> 

Get it and read the release note as well as ChangeLogs. It may solve
your problem. You also need binutils 2.9.1.0.19a or above.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> hjl@lucon.org (H.J. Lu):

>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1

> When you use Linux, it is always a good idea to try my egcs for Linux.
> You can find it in the egcs list archive.

Thanx for the tip.  Umm... you wouldn't have a more specific location
of your egcs variant (eg. which list?  And when?), since the list
archives lack a search mechanism?

What kind of changes have you done?

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Fri, 22 Jan 1999, H.J. Lu wrote:
>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
>
>When you use Linux, it is always a good idea to try my egcs for Linux.
>You can find it in the egcs list archive.
>

Seems that this update of egcs-1.1.1 finally is Ok. I earlier had to manually
edit  libio  to fix some problems when building statically linked executables.
I was not able to reproduce them in small test example and I got them only
when building one rather large appliction. 
 
These problems were conflicting definitions of _IO_*() functions in libstdc++.a
and libc.a.  Finally seems that problems are solved and I no more need
to do changes I did for almost a year (beginning with gcc-2.8.1 in March 1998)

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

> Seems that this update of egcs-1.1.1 finally is Ok. I earlier had to
> manually edit libio to fix some problems when building statically linked
> executables.
...

> These problems were conflicting definitions of _IO_*() functions in
> libstdc++.a and libc.a.

Sigh.  Back when we started egcs, one of my personal priorities was that
we would no longer have to wait for an "HJ special" to have libstdc++
and libc work and play well together on Linux.  We largely succeeded
with 1.0.x.

Please, let's make sure future releases work without HJ having to patch
things up later.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Wed, 27 Jan 1999, Joe Buck wrote:
>> Seems that this update of egcs-1.1.1 finally is Ok. I earlier had to
>> manually edit libio to fix some problems when building statically linked
>> executables.
>...
>
>> These problems were conflicting definitions of _IO_*() functions in
>> libstdc++.a and libc.a.
>
>Sigh.  Back when we started egcs, one of my personal priorities was that
>we would no longer have to wait for an "HJ special" to have libstdc++
>and libc work and play well together on Linux.  We largely succeeded
>with 1.0.x.

egcs-1.0.3 was NOT Ok (at least binaries from Slackware-3.5 and 3.6).
I got problems initially with gcc-2.8.1 + libstdc++-2.8.1. After that I got the
same problems with egcs-1.0.3, egcs-1.1 and egcs-1.1.1. I removed from
libstdc++ all _IO_*() functions that are in libc-5.4.46 as workaround
(all except _IO_getline_info() which is not in libc).  These are things I had to
patch in libstdc++. I don't have simple testsuite that illustrates this problems
which appears only when building some statically linked executables
but "HJ special" version solves it. Here is some fragment of output of 
	nm --extern-only libstdc++ libstdc++-2-libc5-1-2.9.0.a 

iogetc.o:
00000000 T _IO_getc
         U __uflow
00000000 W getc

ioputc.o:
00000000 T _IO_putc
         U __overflow
00000000 W putc

iofeof.o:
00000000 T _IO_feof
00000000 W feof

ioferror.o:
00000000 T _IO_ferror
00000000 W ferror

filedoalloc.o:
00000000 T _IO_file_doallocate
         U _IO_setb
         U isatty
         U mmap

Earlier versions didn't define weak symbols getc, putc etc.  I think that was
the source of problems I met before.

>Please, let's make sure future releases work without HJ having to patch
>things up later.

It would be nice

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Andris Pavenis <andris@stargate.astr.lu.lv>:

> On Wed, 27 Jan 1999, Joe Buck wrote:

>> Sigh.  Back when we started egcs, one of my personal priorities was
>> that we would no longer have to wait for an "HJ special" to have
>> libstdc++ and libc work and play well together on Linux.  We
>> largely succeeded with 1.0.x.

> egcs-1.0.3 was NOT Ok (at least binaries from Slackware-3.5 and 3.6).

egcs-1.0.3 worked OK for me, compiled from source on RedHat 5.0.

If I can't get egcs-1.1.1 working correctly on S.u.S.E. soon, I'll
have to try going back to 1.0.3.

Otherwise I risk having my linux box forcibly rebootet with
WinNT...:-) 

What *is* "type_info info function" anyways...?  Something to do with 
RTTI?

It's in type_info functions my egcs-1.1.1 (now patched with HJ's
patches and with the prescribed binutils) complain about the multiple
definitions referred to in the subject of this article.

I know someone else who's also running 1.1.1 on linux and who gets
similar messages when linking shared libs.  But for him they're only
warnings, not errors.

AFAIK I don't actively use RTTI anywhere, so if I can figure a way to
turn it off I'll try that.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

Platform: egcs-2.91.60.1 19990115/Linux, binutils 2.9.1.0.19a, 
	S.u.S.E. 5.3 linux (libc5)

>>>>> Steinar Bang <sb@metis.no>:

> It's in type_info functions my egcs-1.1.1 (now patched with HJ's
> patches and with the prescribed binutils) complain about the multiple
> definitions referred to in the subject of this article.

See the first attached file.

> I know someone else who's also running 1.1.1 on linux and who gets
> similar messages when linking shared libs.  But for him they're only
> warnings, not errors.

> AFAIK I don't actively use RTTI anywhere, so if I can figure a way to
> turn it off I'll try that.

It wasn't RTTI.  When I used -fno-rtti the error messages just moved
to the next virtual function.  This sort of puts me in mind of the
paragraph below the paragraph mentioning "-fno-rtti" in
	<URL: http://egcs.cygnus.com/egcs-1.1/c++features.html >

This paragraph:
	* On ELF systems, duplicate copies of symbols with
	  'initialized common' linkage (such as template
	  instantiations, vtables, and extern inlines) will now be
	  discarded by the GNU linker, so you don't need to use
	  -frepo.  This support requires GNU ld from binutils 2.8 or
	  later.

In my case, the things complained about aren't used in the .so, but
they exist in header files included indirectly.  When I tried removing 
the list<KMenuElement...> from the header files, I got a longer list
of errors referring to a similar problem in basic_string<char>.

My problem occurs in shared libraries holding self registering
objects.  We subclass a C++ class and implement a singleton object.
We create a static global of this class.  When the shared lib is
loaded, the constructors of these statics will be run, and the
singletons will register themselves.

Right now, I have a problem when I have more than one of these classes 
in an .so.  If I remove the static global of one of the classes, the
problem goes away.

I've tried making a simple test case for these objects, but so far,
I've been unable to produce the errors in this test case.  If I'm able 
to produce a test case, I'll send it to egcs-bugs.


- Steinar


[-- Attachment #2: link-error01.txt --]
[-- Type: text/plain, Size: 2219 bytes --]

cd ~/2x/examples/mmlref/mmlrefmeth/
make 
progen -o "mmlrefmeth.pro" -n "mmlrefmeth" "TEMPLATE=metislib" \
	"CONFIG=dll" "INCLUDEPATH=\$(M2XDIR)/include" \
	"DEPENDPATH=" "DESTDIR=.." \
	"TARGET=mmlrefmeth" "solaris-cc:USE_STL=yes" "solaris-cc:USE_STANDARDS_TOOLKIT=yes" "solaris-cc:USE_TEMPLATE_DB=yes" "LIBS=-L/home/sb/2x/lib -l2x_kernel -ldl -lm" "solaris-gcc:LIBS+= -lstdc++" "DEFINES= OS_USE_EXCEPTIONS" "DEPENDPATH+=/home/sb/2x/include"
tmake mmlrefmeth.pro -o GNUmakefile.debug \
    "DEFINES+=QT_FATAL_ASSERT" "CONFIG+=debug" "OBJECTS_DIR=.obj/debug"
make -f GNUmakefile.debug
make[1]: Entering directory `/home/sb/2x/examples/mmlref/mmlrefmeth'
g++ -c -pipe -g -fPIC -DOS_USE_EXCEPTIONS -DQT_FATAL_ASSERT -I/home/sb/2x/include -o .obj/debug/exprimitiveprice.o exprimitiveprice.cpp
g++ -c -pipe -g -fPIC -DOS_USE_EXCEPTIONS -DQT_FATAL_ASSERT -I/home/sb/2x/include -o .obj/debug/exvirtualprice.o exvirtualprice.cpp
rm -f libmmlrefmeth.so.1.0 libmmlrefmeth.so libmmlrefmeth.so.1
g++ -shared -Wl,-soname,libmmlrefmeth.so.1 -o libmmlrefmeth.so.1.0 .obj/debug/exprimitiveprice.o .obj/debug/exvirtualprice.o  -L/home/sb/2x/lib -l2x_kernel -ldl -lm
.obj/debug/exvirtualprice.o: In function `exVirtualPrice type_info function':
/home/sb/2x/examples/mmlref/mmlrefmeth/exvirtualprice.cpp(.text+0x4): multiple definition of `global destructors keyed to list<KMenuElement *, __default_alloc_template<0, 0> >::clear(void)'
.obj/debug/exprimitiveprice.o(.text+0x4):/home/sb/apps/include/g++-2/std/bastring.h: first defined here
.obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<0, 0> >::global destructors keyed to clear(void)':
/home/sb/apps/include/g++-2/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<0, 0> >::global destructors keyed to clear(void)'
.obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++-2/stl_list.h:304: first defined here
collect2: ld returned 1 exit status
make[1]: *** [../libmmlrefmeth.so.1.0] Error 1
make[1]: Leaving directory `/home/sb/2x/examples/mmlref/mmlrefmeth'
make: *** [debug] Error 2

Compilation exited abnormally with code 2 at Fri Jan 29 10:48:14

[-- Attachment #3: link-error02.txt --]
[-- Type: text/plain, Size: 2216 bytes --]

cd ~/2x/examples/mmlref/mmlrefmeth/
make 
progen -o "mmlrefmeth.pro" -n "mmlrefmeth" "TEMPLATE=metislib" \
	"CONFIG=dll" "INCLUDEPATH=\$(M2XDIR)/include" \
	"DEPENDPATH=" "DESTDIR=.." \
	"TARGET=mmlrefmeth" "solaris-cc:USE_STL=yes" "solaris-cc:USE_STANDARDS_TOOLKIT=yes" "solaris-cc:USE_TEMPLATE_DB=yes" "LIBS=-L/home/sb/2x/lib -l2x_kernel -ldl -lm" "solaris-gcc:LIBS+= -lstdc++" "DEFINES= OS_USE_EXCEPTIONS" "DEPENDPATH+=/home/sb/2x/include"
tmake mmlrefmeth.pro -o GNUmakefile.debug \
    "DEFINES+=QT_FATAL_ASSERT" "CONFIG+=debug" "OBJECTS_DIR=.obj/debug"
make -f GNUmakefile.debug
make[1]: Entering directory `/home/sb/2x/examples/mmlref/mmlrefmeth'
g++ -c -pipe -fno-rtti -g -fPIC -DOS_USE_EXCEPTIONS -DQT_FATAL_ASSERT -I/home/sb/2x/include -o .obj/debug/exprimitiveprice.o exprimitiveprice.cpp
g++ -c -pipe -fno-rtti -g -fPIC -DOS_USE_EXCEPTIONS -DQT_FATAL_ASSERT -I/home/sb/2x/include -o .obj/debug/exvirtualprice.o exvirtualprice.cpp
rm -f libmmlrefmeth.so.1.0 libmmlrefmeth.so libmmlrefmeth.so.1
g++ -shared -Wl,-soname,libmmlrefmeth.so.1 -o libmmlrefmeth.so.1.0 .obj/debug/exprimitiveprice.o .obj/debug/exvirtualprice.o  -L/home/sb/2x/lib -l2x_kernel -ldl -lm
.obj/debug/exvirtualprice.o: In function `exVirtualPrice::run(KMethodContext &)':
/home/sb/2x/include/kpointer.h(.text+0x4): multiple definition of `global destructors keyed to list<KMenuElement *, __default_alloc_template<0, 0> >::clear(void)'
.obj/debug/exprimitiveprice.o(.text+0x4):/home/sb/apps/include/g++-2/std/bastring.h: first defined here
.obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<0, 0> >::global destructors keyed to clear(void)':
/home/sb/apps/include/g++-2/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<0, 0> >::global destructors keyed to clear(void)'
.obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++-2/stl_list.h:304: first defined here
collect2: ld returned 1 exit status
make[1]: *** [../libmmlrefmeth.so.1.0] Error 1
make[1]: Leaving directory `/home/sb/2x/examples/mmlref/mmlrefmeth'
make: *** [debug] Error 2

Compilation exited abnormally with code 2 at Fri Jan 29 12:32:47

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 	  later.
> 
> In my case, the things complained about aren't used in the .so, but
> they exist in header files included indirectly.  When I tried removing 
> the list<KMenuElement...> from the header files, I got a longer list
> of errors referring to a similar problem in basic_string<char>.
> 
> My problem occurs in shared libraries holding self registering
> objects.  We subclass a C++ class and implement a singleton object.
> We create a static global of this class.  When the shared lib is
> loaded, the constructors of these statics will be run, and the
> singletons will register themselves.
> 
> Right now, I have a problem when I have more than one of these classes 
> in an .so.  If I remove the static global of one of the classes, the
> problem goes away.
> 
> I've tried making a simple test case for these objects, but so far,
> I've been unable to produce the errors in this test case.  If I'm able 
> to produce a test case, I'll send it to egcs-bugs.
> 

It sounds like a bug I fixed in Crypto++ 3.0. If you can send me
a testcase, I will look into it. I can hanle the big testcase as
long as it is less than 4MB, compressed.


H.J.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Andris Pavenis <andris@stargate.astr.lu.lv>:
> 
> > On Wed, 27 Jan 1999, Joe Buck wrote:
> 
> >> Sigh.  Back when we started egcs, one of my personal priorities was
> >> that we would no longer have to wait for an "HJ special" to have
> >> libstdc++ and libc work and play well together on Linux.  We
> >> largely succeeded with 1.0.x.
> 
> > egcs-1.0.3 was NOT Ok (at least binaries from Slackware-3.5 and 3.6).
> 
> egcs-1.0.3 worked OK for me, compiled from source on RedHat 5.0.

RedHat 5.0 uses glibc 2. It doesn't have the libio problem. My patch
for egcs 1.1.1/Linux fixes the libc 5 problem.


H.J.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

HJ writes:

> RedHat 5.0 uses glibc 2. It doesn't have the libio problem. My patch
> for egcs 1.1.1/Linux fixes the libc 5 problem.

Yes, but we'd fixed this before for 1.0.x, so it seems we let the release
out without fixing it again.  In the future, let's make sure that libc5
works.

My home system is still running Red Hat 4.2, so I can help with this.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199901300155.RAA02173@atrus.synopsys.com >you write:
  > HJ writes:
  > 
  > > RedHat 5.0 uses glibc 2. It doesn't have the libio problem. My patch
  > > for egcs 1.1.1/Linux fixes the libc 5 problem.
  > 
  > Yes, but we'd fixed this before for 1.0.x, so it seems we let the release
  > out without fixing it again.  In the future, let's make sure that libc5
  > works.
  > 
  > My home system is still running Red Hat 4.2, so I can help with this.
What precisely is the "libio" problem?  I'm planning on making an egcs-1.1.2
pre-release in the next few days.  If the "libio" problem is serious and the
fix is safe we can probable include it.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Sat, 30 Jan 1999, Jeffrey A Law wrote:
>In message < 199901300155.RAA02173@atrus.synopsys.com >you write:
>  > HJ writes:
>  > 
>  > > RedHat 5.0 uses glibc 2. It doesn't have the libio problem. My patch
>  > > for egcs 1.1.1/Linux fixes the libc 5 problem.
>  > 
>  > Yes, but we'd fixed this before for 1.0.x, so it seems we let the release
>  > out without fixing it again.  In the future, let's make sure that libc5
>  > works.
>  > 
>  > My home system is still running Red Hat 4.2, so I can help with this.
>What precisely is the "libio" problem?  I'm planning on making an egcs-1.1.2
>pre-release in the next few days.  If the "libio" problem is serious and the
>fix is safe we can probable include it.
>

It only matters if one is building statically linked executable and even then
not always. I don't even have small testsuite that could ilustrate this problem.

Initially I mentioned this problem in egcs-bugs about half a year ago.

	http://www.cygnus.com/ml/egcs-bugs/1998-Jul/0598.html
	http://www.cygnus.com/ml/egcs-bugs/1998-Jul/0605.html

But of course I think that HJ patch solves this problem better than my 
rather ugly workaround I described in second message.

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

> What precisely is the "libio" problem?  I'm planning on making an egcs-1.1.2
> pre-release in the next few days.  If the "libio" problem is serious and the
> fix is safe we can probable include it.

It refers to clashes between the libio code in libstdc++ and the C
library.  It is caused by the fact that both libc5.x and libstdc++
have different versions of the same code. 

pparently the egcs1.1 problems are much less severe than the ones we used
to have, but some users have reported problems.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

> What precisely is the "libio" problem?  I'm planning on making an egcs-1.1.2
> pre-release in the next few days.  If the "libio" problem is serious and the
> fix is safe we can probable include it.

It refers to clashes between the libio code in libstdc++ and the C
library.  It is caused by the fact that both libc5.x and libstdc++
have different versions of the same code. 

pparently the egcs1.1 problems are much less severe than the ones we used
to have, but some users have reported problems.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Thu, 28 Jan 1999, Steinar Bang wrote:
>>>>>> Andris Pavenis <andris@stargate.astr.lu.lv>:
>
>> On Wed, 27 Jan 1999, Joe Buck wrote:
>
>>> Sigh.  Back when we started egcs, one of my personal priorities was
>>> that we would no longer have to wait for an "HJ special" to have
>>> libstdc++ and libc work and play well together on Linux.  We
>>> largely succeeded with 1.0.x.
>
>> egcs-1.0.3 was NOT Ok (at least binaries from Slackware-3.5 and 3.6).
>
>egcs-1.0.3 worked OK for me, compiled from source on RedHat 5.0.

It was a problem that appeared in very special situation when linking 
rather big application (that uses many libraries and is written mostly
in C++) statically. This problem does not appear when linking with shared
libstdc++ and libc.

Therefore I think only very few users have met this problem.

>If I can't get egcs-1.1.1 working correctly on S.u.S.E. soon, I'll
>have to try going back to 1.0.3.
>
>Otherwise I risk having my linux box forcibly rebootet with
>WinNT...:-) 
>
>What *is* "type_info info function" anyways...?  Something to do with 
>RTTI?
>
>It's in type_info functions my egcs-1.1.1 (now patched with HJ's
>patches and with the prescribed binutils) complain about the multiple
>definitions referred to in the subject of this article.
>
>I know someone else who's also running 1.1.1 on linux and who gets
>similar messages when linking shared libs.  But for him they're only
>warnings, not errors.

First thing to do after upgrading gcc is to rebuild ALL (!!!!) C++ sources
with new compiler. It includes of course also libraries built from C++ 
sources (for example Qt-1.41 or Qt-1.42)

Also make sure that  libstdc++.so  doesn't point to old shared library

>
>AFAIK I don't actively use RTTI anywhere, so if I can figure a way to
>turn it off I'll try that.

-fno-rtti

Also if You are not using C++ exceptions You can turn them of with

-fno-exceptions

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Andris Pavenis <andris@stargate.astr.lu.lv>:

> First thing to do after upgrading gcc is to rebuild ALL (!!!!) C++
> sources with new compiler. It includes of course also libraries
> built from C++ sources (for example Qt-1.41 or Qt-1.42)

I know.  I did.  Several times actually, after trying egcs-1.1.1 with
different configurations and the HJ patch.

> Also make sure that libstdc++.so doesn't point to old shared library

The old shared library was history.

>> AFAIK I don't actively use RTTI anywhere, so if I can figure a way to
>> turn it off I'll try that.

> -fno-rtti

I know.  I found out.  That wasn't the problem.  When I disabled RTTI
the error just moved to the next virtual function.

I isolated a small test case for the problem that I sent to HJ on
friday.  It can be found at:
	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Andris Pavenis <andris@stargate.astr.lu.lv>:

> First thing to do after upgrading gcc is to rebuild ALL (!!!!) C++
> sources with new compiler. It includes of course also libraries
> built from C++ sources (for example Qt-1.41 or Qt-1.42)

I know.  I did.  Several times actually, after trying egcs-1.1.1 with
different configurations and the HJ patch.

> Also make sure that libstdc++.so doesn't point to old shared library

The old shared library was history.

>> AFAIK I don't actively use RTTI anywhere, so if I can figure a way to
>> turn it off I'll try that.

> -fno-rtti

I know.  I found out.  That wasn't the problem.  When I disabled RTTI
the error just moved to the next virtual function.

I isolated a small test case for the problem that I sent to HJ on
friday.  It can be found at:
	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Andris Pavenis <andris@stargate.astr.lu.lv>:

> On Wed, 27 Jan 1999, Joe Buck wrote:

>> Sigh.  Back when we started egcs, one of my personal priorities was
>> that we would no longer have to wait for an "HJ special" to have
>> libstdc++ and libc work and play well together on Linux.  We
>> largely succeeded with 1.0.x.

> egcs-1.0.3 was NOT Ok (at least binaries from Slackware-3.5 and 3.6).

egcs-1.0.3 worked OK for me, compiled from source on RedHat 5.0.

If I can't get egcs-1.1.1 working correctly on S.u.S.E. soon, I'll
have to try going back to 1.0.3.

Otherwise I risk having my linux box forcibly rebootet with
WinNT...:-) 

What *is* "type_info info function" anyways...?  Something to do with 
RTTI?

It's in type_info functions my egcs-1.1.1 (now patched with HJ's
patches and with the prescribed binutils) complain about the multiple
definitions referred to in the subject of this article.

I know someone else who's also running 1.1.1 on linux and who gets
similar messages when linking shared libs.  But for him they're only
warnings, not errors.

AFAIK I don't actively use RTTI anywhere, so if I can figure a way to
turn it off I'll try that.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Wed, 27 Jan 1999, Joe Buck wrote:
>> Seems that this update of egcs-1.1.1 finally is Ok. I earlier had to
>> manually edit libio to fix some problems when building statically linked
>> executables.
>...
>
>> These problems were conflicting definitions of _IO_*() functions in
>> libstdc++.a and libc.a.
>
>Sigh.  Back when we started egcs, one of my personal priorities was that
>we would no longer have to wait for an "HJ special" to have libstdc++
>and libc work and play well together on Linux.  We largely succeeded
>with 1.0.x.

egcs-1.0.3 was NOT Ok (at least binaries from Slackware-3.5 and 3.6).
I got problems initially with gcc-2.8.1 + libstdc++-2.8.1. After that I got the
same problems with egcs-1.0.3, egcs-1.1 and egcs-1.1.1. I removed from
libstdc++ all _IO_*() functions that are in libc-5.4.46 as workaround
(all except _IO_getline_info() which is not in libc).  These are things I had to
patch in libstdc++. I don't have simple testsuite that illustrates this problems
which appears only when building some statically linked executables
but "HJ special" version solves it. Here is some fragment of output of 
	nm --extern-only libstdc++ libstdc++-2-libc5-1-2.9.0.a 

iogetc.o:
00000000 T _IO_getc
         U __uflow
00000000 W getc

ioputc.o:
00000000 T _IO_putc
         U __overflow
00000000 W putc

iofeof.o:
00000000 T _IO_feof
00000000 W feof

ioferror.o:
00000000 T _IO_ferror
00000000 W ferror

filedoalloc.o:
00000000 T _IO_file_doallocate
         U _IO_setb
         U isatty
         U mmap

Earlier versions didn't define weak symbols getc, putc etc.  I think that was
the source of problems I met before.

>Please, let's make sure future releases work without HJ having to patch
>things up later.

It would be nice

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > These problems were conflicting definitions of _IO_*() functions in
> > libstdc++.a and libc.a.
> 
> Sigh.  Back when we started egcs, one of my personal priorities was that
> we would no longer have to wait for an "HJ special" to have libstdc++
> and libc work and play well together on Linux.  We largely succeeded
> with 1.0.x.

How about SMP and parallel build?

> 
> Please, let's make sure future releases work without HJ having to patch
> things up later.
> 

I am glad you bring this issue up again. I have a few patches for
libf2c and libio, besides this one. They are for SMP, parallel build
and  "make check" with options. It seems noone really cares it,
especially for libf2c. It is too bad.

BTW, I will submit another SMP patch for libio/libstdc++ soon.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[craig]

>I am glad you bring this issue up again. I have a few patches for
>libf2c and libio, besides this one. They are for SMP, parallel build
>and  "make check" with options. It seems noone really cares it,
>especially for libf2c. It is too bad.

Don't assume g77 people don't care about your libf2c patch.  I've
been pretty much out-to-lunch on g77 stuff for some time now, though
am slowly crawling back using NT (New Technology, like real email,
CVS, and so on) so I can resume work without having to depend so
much on others doing my job.

Anyway, I don't recall seeing such patches for libf2c, but they might
be buried in my mailbox.  It wouldn't hurt to resend them to egcs-patches.

        tq vm, (burley)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >I am glad you bring this issue up again. I have a few patches for
> >libf2c and libio, besides this one. They are for SMP, parallel build
> >and  "make check" with options. It seems noone really cares it,
> >especially for libf2c. It is too bad.
> 
> Don't assume g77 people don't care about your libf2c patch.  I've
> been pretty much out-to-lunch on g77 stuff for some time now, though
> am slowly crawling back using NT (New Technology, like real email,
> CVS, and so on) so I can resume work without having to depend so
> much on others doing my job.
> 
> Anyway, I don't recall seeing such patches for libf2c, but they might
> be buried in my mailbox.  It wouldn't hurt to resend them to egcs-patches.

Here they are again:

http://www.cygnus.com/ml/egcs-patches/1999-Jan/0265.html
http://www.cygnus.com/ml/egcs-patches/1998-Oct/0063.html

The discussion and inaction around those threads leave me an impression
that noone from libf2c really cares or understands what is going. I am
more than happy to be proved wrong on that.



-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[craig]

Thanks for the patch-pointers, they're in my email in-box for me to
get to someday.

>The discussion and inaction around those threads leave me an impression
>that noone from libf2c really cares or understands what is going. I am
>more than happy to be proved wrong on that.

Don't hold yer breath.  :)  I'm sure there's a good amount of *caring*,
but time and understanding are in short supply.

Remember that libf2c isn't "grown" in these parts -- it's from netlib --
so egcs/libf2c is really libg2c, a version of libf2c modified to be
generally compatible with libf2c but more appropriate for use with g77
than vanilla libf2c.

So there's not really any individual developer who works on libf2c as
the run-time library for g77, in the same sense that there probably is
at least one for glibc, libc5, etc.  That is, the person who best
understands libf2c does not work on g77, egcs, gcc2, or anything like
that (though he's been generally quite willing to change libf2c to
accommodate g77 needs to seem general-purpose enough).

Normally, Dave Love takes care of the libU77 part of libg2c (there's
no libU77 in libf2c) and all the configury stuff.  I've made changes
to the libF77 and, especially, libI77 areas, but I've been out-to-lunch
for a couple of months now (at least), which should change soon.

Another wrinkle is that we (the g77 people) have been still trying to
support FSF-g77 in some fashion, so we avoid making too many changes
to egcs-libg2c that can't be directly put in FSF-g77-libg2c.

So, things should improve, but I can't promise when or by how much.

Someday maybe libg77 -- a run-time library designed to work solely with
and for g77 -- will happen.  In one sense, that'll make for more
development and maintenance effort overall, but it'll be more monolithic:
the problems of coping with different versions of something not really
designed for g77 won't be there, so what'll be left will, while larger,
will be more straightforward to deal with.

        tq vm, (burley)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[craig]

Thanks for the patch-pointers, they're in my email in-box for me to
get to someday.

>The discussion and inaction around those threads leave me an impression
>that noone from libf2c really cares or understands what is going. I am
>more than happy to be proved wrong on that.

Don't hold yer breath.  :)  I'm sure there's a good amount of *caring*,
but time and understanding are in short supply.

Remember that libf2c isn't "grown" in these parts -- it's from netlib --
so egcs/libf2c is really libg2c, a version of libf2c modified to be
generally compatible with libf2c but more appropriate for use with g77
than vanilla libf2c.

So there's not really any individual developer who works on libf2c as
the run-time library for g77, in the same sense that there probably is
at least one for glibc, libc5, etc.  That is, the person who best
understands libf2c does not work on g77, egcs, gcc2, or anything like
that (though he's been generally quite willing to change libf2c to
accommodate g77 needs to seem general-purpose enough).

Normally, Dave Love takes care of the libU77 part of libg2c (there's
no libU77 in libf2c) and all the configury stuff.  I've made changes
to the libF77 and, especially, libI77 areas, but I've been out-to-lunch
for a couple of months now (at least), which should change soon.

Another wrinkle is that we (the g77 people) have been still trying to
support FSF-g77 in some fashion, so we avoid making too many changes
to egcs-libg2c that can't be directly put in FSF-g77-libg2c.

So, things should improve, but I can't promise when or by how much.

Someday maybe libg77 -- a run-time library designed to work solely with
and for g77 -- will happen.  In one sense, that'll make for more
development and maintenance effort overall, but it'll be more monolithic:
the problems of coping with different versions of something not really
designed for g77 won't be there, so what'll be left will, while larger,
will be more straightforward to deal with.

        tq vm, (burley)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[craig]

>I am glad you bring this issue up again. I have a few patches for
>libf2c and libio, besides this one. They are for SMP, parallel build
>and  "make check" with options. It seems noone really cares it,
>especially for libf2c. It is too bad.

Don't assume g77 people don't care about your libf2c patch.  I've
been pretty much out-to-lunch on g77 stuff for some time now, though
am slowly crawling back using NT (New Technology, like real email,
CVS, and so on) so I can resume work without having to depend so
much on others doing my job.

Anyway, I don't recall seeing such patches for libf2c, but they might
be buried in my mailbox.  It wouldn't hurt to resend them to egcs-patches.

        tq vm, (burley)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

> Seems that this update of egcs-1.1.1 finally is Ok. I earlier had to
> manually edit libio to fix some problems when building statically linked
> executables.
...

> These problems were conflicting definitions of _IO_*() functions in
> libstdc++.a and libc.a.

Sigh.  Back when we started egcs, one of my personal priorities was that
we would no longer have to wait for an "HJ special" to have libstdc++
and libc work and play well together on Linux.  We largely succeeded
with 1.0.x.

Please, let's make sure future releases work without HJ having to patch
things up later.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Fri, 22 Jan 1999, H.J. Lu wrote:
>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> 
>> >>>>> Steinar Bang <sb@metis.no>:
>> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
>
>When you use Linux, it is always a good idea to try my egcs for Linux.
>You can find it in the egcs list archive.
>

Seems that this update of egcs-1.1.1 finally is Ok. I earlier had to manually
edit  libio  to fix some problems when building statically linked executables.
I was not able to reproduce them in small test example and I got them only
when building one rather large appliction. 
 
These problems were conflicting definitions of _IO_*() functions in libstdc++.a
and libc.a.  Finally seems that problems are solved and I no more need
to do changes I did for almost a year (beginning with gcc-2.8.1 in March 1998)

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Steinar Bang <sb@metis.no>:
> 
> >>>>> Steinar Bang <sb@metis.no>:
> >> Platform: linux S.u.S.E. 5.3, egcs 1.1.1

When you use Linux, it is always a good idea to try my egcs for Linux.
You can find it in the egcs list archive.


H.J.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
>> I'm getting messages of the following type:
>> .obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)':
>> /home/sb/apps/include/g++/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)'
>> .obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++/stl_list.h:304: first defined here
>> collect2: ld returned 1 exit status
>> when linking some (not all) of my shared libraries.

>> I can't remember having seen any of these with egcs 1.0.3.  

[snip!]

> Hm... it suddenly struck me that I've been running with
> --enable-shared, and that this is not a default option, *and* that it
> affects linking.

I unpacked 1.1.1, configured without --enable-shared, compiled with
"make bootstrap", and installed it.

I still get the exact same error messages when linking some of my
shared libs.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> Platform: linux S.u.S.E. 5.3, egcs 1.1.1
> I'm getting messages of the following type:
> 	.obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)':
> 	/home/sb/apps/include/g++/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)'
> 	.obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++/stl_list.h:304: first defined here
> 	collect2: ld returned 1 exit status
> when linking some (not all) of my shared libraries.

> I can't remember having seen any of these with egcs 1.0.3.  

> Searches on Alta Vista for this problem found no meaningful responses,
> searches on Deja News for "egcs & multiple & definition & keyed" gave
> me two persons with the same problem on linux, in october last year
> (and one "article unavailable"), but no responses.

Hm... it suddenly struck me that I've been running with
--enable-shared, and that this is not a default option, *and* that it
affects linking.

I'm now doing a brand new "make bootstrap" of egcs-1.1.1 (for the
second time, the first crashed in the installation phase for
libiberty.a and didn't install essential parts of the compiler
(eg. cc1plus).  So I cleaned away everything and am doing a brand new
bootstrap).

multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

Platform: linux S.u.S.E. 5.3, egcs 1.1.1

I'm getting messages of the following type:
	.obj/debug/exvirtualprice.o: In function `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)':
	/home/sb/apps/include/g++/stl_list.h:304: multiple definition of `global constructors keyed to list<KMenuElement *, __default_alloc_template<false, 0> >::global destructors keyed to clear(void)'
	.obj/debug/exprimitiveprice.o:/home/sb/apps/include/g++/stl_list.h:304: first defined here
	collect2: ld returned 1 exit status
when linking some (not all) of my shared libraries.

I can't remember having seen any of these with egcs 1.0.3.  

Searches on Alta Vista for this problem found no meaningful responses,
searches on Deja News for "egcs & multiple & definition & keyed" gave
me two persons with the same problem on linux, in october last year
(and one "article unavailable"), but no responses.

I got a response from one of the two today, and he lost the problem by 
rewriting all of the code that used STL.  Then the problem
mysteriously went away.

Not a good sign...

I'll isolate a test case if I can.

Re: problem building linux specific 1.1.1

[N8TM]

In a message dated 1/25/99 3:53:51 AM Pacific Standard Time, sb@metis.no
writes:

<< Hm... I have patch 2.1 it seems.  At least that's what "patch -v"
 reports.  >>
patch-2.1 was working for me when I installed egcs-1.1.1 on linux-gnulibc1 and
Irix6.4, but it failed on recent snapshots, so I've switched to patch-2.5.

Re: problem building linux specific 1.1.1

[N8TM]

In a message dated 1/25/99 3:53:51 AM Pacific Standard Time, sb@metis.no
writes:

<< Hm... I have patch 2.1 it seems.  At least that's what "patch -v"
 reports.  >>
patch-2.1 was working for me when I installed egcs-1.1.1 on linux-gnulibc1 and
Irix6.4, but it failed on recent snapshots, so I've switched to patch-2.5.