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: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

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

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

>> But I'll keep working at isolating the problem and try to make a
>> smaller test case without all the cluttering.


Here's a minimal test case that gives me the following output on
egcs-2.91.60.1 19990115/Linux, binutils-2.9.1.0.19a, S.u.S.E. 5.3
linux (w/libc5):

make
g++ -fPIC   -c b.cc -o b.o
g++ -fPIC   -c c.cc -o c.o
g++ -shared -Wl,-soname,libdummy.so.1 -o libdummy.so.1.0  b.o  c.o
c.o: In function `global destructors keyed to int lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed char const *, signed char const *)':
c.o(.text+0x4): multiple definition of `global destructors keyed to int lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed char const *, signed char const *)'
b.o(.text+0x4): first defined here
c.o: In function `global constructors keyed to int global destructors keyed to lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed char const *, signed char const *)':
c.o(.text+0x34): multiple definition of `global constructors keyed to int global destructors keyed to lexicographical_compare_3way<signed char const *, signed char const *>(signed char const *, signed char const *, signed char const *, signed char const *)'
b.o(.text+0x34): first defined here
collect2: ld returned 1 exit status
make: *** [libdummy.so.1.0] Error 1

Removing the static in either b.cc or c.cc makes the link error go
away.


- Steinar

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

[H.J. Lu]

Hi,

I have no idea if this patch is correct. But it works for me. gcc
seems to pick a poor choice of function name for global constructors
and destructors. It may not be unique across files.

Thanks.

H.J.
----
Fri Jan 29 17:15:59 1999  H.J. Lu  (hjl@gnu.org)

	* decl2.c (start_objects): Make global constructors and
	destructors unique.


--- ../../../../import/egcs-1.1.1/egcs/gcc/cp/decl2.c	Mon Nov  9 01:32:04 1998
+++ ./decl2.c	Fri Jan 29 17:18:18 1999
@@ -2943,6 +2943,12 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+  /* It is a file scope function. */
+  if (flag_weak)
+    make_decl_one_only (current_function_decl);
+  else
+    TREE_PUBLIC (current_function_decl) = 0;
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();



--
Forwarded message:

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

[Alexandre Oliva]

On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:

> I have no idea if this patch is correct. But it works for me. gcc
> seems to pick a poor choice of function name for global constructors
> and destructors. It may not be unique across files.

AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
matter of porting his fix to the branch.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

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

[H.J. Lu]

> 
> On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
> 
> > I have no idea if this patch is correct. But it works for me. gcc
> > seems to pick a poor choice of function name for global constructors
> > and destructors. It may not be unique across files.
> 
> AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
> matter of porting his fix to the branch.
> 

I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
is not 100% safe since it bets on luck. My second patch is 100% safe.
But it only covers ctors/dtors in C++ and only works on ELF.

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

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

[Jeffrey A Law]

  In message < m106iAc-000390C@ocean.lucon.org >you write:
  > > 
  > > On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
  > > 
  > > > I have no idea if this patch is correct. But it works for me. gcc
  > > > seems to pick a poor choice of function name for global constructors
  > > > and destructors. It may not be unique across files.
  > > 
  > > AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
  > > matter of porting his fix to the branch.
  > > 
  > 
  > I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
  > is not 100% safe since it bets on luck. My second patch is 100% safe.
  > But it only covers ctors/dtors in C++ and only works on ELF.
In what way does it "bets on luck"?

Such statements carry far more weight when you take the time to explain them.

jeff

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

[H.J. Lu]

> 
> 
>   In message < m106iAc-000390C@ocean.lucon.org >you write:
>   > > 
>   > > On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
>   > > 
>   > > > I have no idea if this patch is correct. But it works for me. gcc
>   > > > seems to pick a poor choice of function name for global constructors
>   > > > and destructors. It may not be unique across files.
>   > > 
>   > > AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
>   > > matter of porting his fix to the branch.
>   > > 
>   > 
>   > I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
>   > is not 100% safe since it bets on luck. My second patch is 100% safe.
>   > But it only covers ctors/dtors in C++ and only works on ELF.
> In what way does it "bets on luck"?
> 
> Such statements carry far more weight when you take the time to explain them.
> 

I will try to explain it here. This is from tree.c:

/* Generate a name for a function unique to this translation unit.
   TYPE is some string to identify the purpose of this function to the
   linker or collect2.  */
       
tree
get_file_function_name_long (type)
     char *type;
{
  ...
}

It is ok if the function is really local to the translation unit.
Let's assume the condition is true. Then there is no need to call
append_random_chars (). We can use a static counter for that
purpose.

Unfortunately, the comments for get_file_function_name_long () are
misleading. Under certain conditions, it is called to generate a name
for a global function unique to the resulting executable binary and all
the shared libraries it uses. One such a case is start_objects () in
cp/decl2.c. It calls get_file_function_name_long to generate a
global function which is used for the C++ file scope constructors
and destructors. My guess for making it global is on some platforms
collect2 is needed to pull out those functions to make sure they
are called at the right time and order. Since it is global, it has
to be unique the executable and all the shared libraries it uses.
Otherwise, you will get a linker error. Even worse a wrong function
may be called. I think it may happen with shared libraries. Linker
may override the function in shared libraries with the one in the
executable if they have the same name. This may lead to disaster
for everyone.

My questions are

1. Can we identify the cases where get_file_function_name_long () is
called to generate a name for a global function unique to the
resulting executable binary and all the shared libraries it uses?
2. Do they have to be global?

In case of the C++ ctor/dtor, collect2 is not needed for ELF, we can
make it local. My patch does that. If they have to be global, we can
add strftime () with hostname in addition to append_random_chars ().
It should have better chances to be unique. But I really want to get
rid of the global function all together.


H.J.

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

[Martin v. Loewis]

> 1. Can we identify the cases where get_file_function_name_long () is
> called to generate a name for a global function unique to the
> resulting executable binary and all the shared libraries it uses?

There are currently three different 'type' arguments passed to that
function, 'D', 'I', and 'N'. For 'D' and 'I', additional mangling
might indicate the initializer priority. For 'N', the resulting name
will be an anonymous namespace.

> 2. Do they have to be global?

In the case of anonymous namespaces, absolutely, yes. I proposed to
make anonymous namespaces (and everything inside) static at one time,
but it was decided that this approach would defeat upcoming
implementations of exported templates.

Regards,
Martin

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

[H.J. Lu]

> 
> > 1. Can we identify the cases where get_file_function_name_long () is
> > called to generate a name for a global function unique to the
> > resulting executable binary and all the shared libraries it uses?
> 
> There are currently three different 'type' arguments passed to that
> function, 'D', 'I', and 'N'. For 'D' and 'I', additional mangling
> might indicate the initializer priority. For 'N', the resulting name
> will be an anonymous namespace.

Do 'D' and 'I' have to be global?

> 
> > 2. Do they have to be global?
> 
> In the case of anonymous namespaces, absolutely, yes. I proposed to
> make anonymous namespaces (and everything inside) static at one time,
> but it was decided that this approach would defeat upcoming
> implementations of exported templates.
> 

I am not sure if we should worry about anonymous namespaces. What
will happen when 2 anonymous namespaces have the same name?


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

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

[Martin v. Loewis]

> Do 'D' and 'I' have to be global?

I'm not sure. As you've found, they don't have to be for ELF. I don't
know what the rationale was for making them global; it seems this
knowledge is lost...

> I am not sure if we should worry about anonymous namespaces. What
> will happen when 2 anonymous namespaces have the same name?

Bad things. Anonymous namespaces allow you to put

namespace{
  int dummy;
}

into a header file, and you should get a different variable in each
object file. More importantly, you can do

namespace{
  class Handle{
    Handle(){}
  };
}

in an implementation and expect that it won't clash with somebody
else's Handle class. If the two anonymous namespaces have the same
name, you'll get a clash.

Regards,
Martin

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

[H.J. Lu]

> 
> > Do 'D' and 'I' have to be global?
> 
> I'm not sure. As you've found, they don't have to be for ELF. I don't
> know what the rationale was for making them global; it seems this
> knowledge is lost...
> 

collect2 is used for globcl ctors/dtors on some systems.

> > I am not sure if we should worry about anonymous namespaces. What
> > will happen when 2 anonymous namespaces have the same name?
> 
> Bad things. Anonymous namespaces allow you to put
> 
> namespace{
>   int dummy;
> }
> 
> into a header file, and you should get a different variable in each
> object file. More importantly, you can do
> 
> namespace{
>   class Handle{
>     Handle(){}
>   };
> }
> 
> in an implementation and expect that it won't clash with somebody
> else's Handle class. If the two anonymous namespaces have the same
> name, you'll get a clash.

How about we use

	machinename+pid+filename+strftime+staticcounter+randomstuff

The possiblility for clash should be very low. I'd like to see it
be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

Thanks.


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

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

[Martin v. Loewis]

> How about we use
> 
> 	machinename+pid+filename+strftime+staticcounter+randomstuff
> 
> The possiblility for clash should be very low. I'd like to see it
> be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

I just had a complaint of somebody running into the same problem,
different scenario:

He had a number of shared libraries, all starting with the same global
function. Of course, this is ill-formed (duplicate definitions), but
the linker didn't complain, so he thought it's all-right. But it
wasn't: g++ keyed initializers to this function, and the same
initializer got invoked twice; another initializer wasn't called.

So I now think that the initializer symbols should be static if we are
not collect2ing them. 

Still, coming up with a better 'unique hash' is worthwhile. It should
be well-designed though: We had several attempts to do it right, and
still didn't. In your proposal, I see a number of problems:

a) pid, randomstuff might not be available on all systems. In
   particular, systems that don't get initializers right probably
   don't have a number of other things.

b) Don't produce too long strings. It might exceed assembler
   restrictions.

Regards,
Martin
 

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

[H.J. Lu]

> 
> > How about we use
> > 
> > 	machinename+pid+filename+strftime+staticcounter+randomstuff
> > 
> > The possiblility for clash should be very low. I'd like to see it
> > be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.
> 
> I just had a complaint of somebody running into the same problem,
> different scenario:
> 
> He had a number of shared libraries, all starting with the same global
> function. Of course, this is ill-formed (duplicate definitions), but
> the linker didn't complain, so he thought it's all-right. But it
> wasn't: g++ keyed initializers to this function, and the same
> initializer got invoked twice; another initializer wasn't called.
> 
> So I now think that the initializer symbols should be static if we are
> not collect2ing them. 

That is what I have been saying all along.

> 
> Still, coming up with a better 'unique hash' is worthwhile. It should
> be well-designed though: We had several attempts to do it right, and
> still didn't. In your proposal, I see a number of problems:
> 
> a) pid, randomstuff might not be available on all systems. In
>    particular, systems that don't get initializers right probably
>    don't have a number of other things.
> 
> b) Don't produce too long strings. It might exceed assembler
>    restrictions.
> 

My proposal does have some limitations. I hope someone can come
up with a better solution. This serious bug must be fixed in
egcs 1.1.2. The sooner, the better.

Please remember we need a universal unique hash for every different
file on every single machine for the same platform. It is a tough
one. But we have to do it.

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

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

[Jeffrey A Law]

  In message < m108PtF-00038sC@ocean.lucon.org >you write:
  > My proposal does have some limitations. I hope someone can come
  > up with a better solution. This serious bug must be fixed in
  > egcs 1.1.2. The sooner, the better.
So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
concrete yet.


jeff

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

[Martin v. Loewis]

> So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> concrete yet.

I think the minimal solution is to make initializer symbols static on
ELF systems. HJ has a patch, although I haven't reviewed it to see
whether it does what it promises to do.

If somebody can propose a patch that produces significantly
more-unique symbols than the current code, this should also go into 1.2.
In this respect, HJ's other patch does not qualify, IMHO.

Regards,
Martin

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

[H.J. Lu]

> 
> > So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> > concrete yet.
> 
> I think the minimal solution is to make initializer symbols static on
> ELF systems. HJ has a patch, although I haven't reviewed it to see
> whether it does what it promises to do.

I am only interested in Linux. If we really cannot fix the problem for
all platforms, it is ok with me as long as Linux is ok :-(.

> 
> If somebody can propose a patch that produces significantly
> more-unique symbols than the current code, this should also go into 1.2.
> In this respect, HJ's other patch does not qualify, IMHO.
> 

To me, "significantly more-unique" is still bet on luck. I really
don't like it. I will do something for Linux one way or the other
if I don't like what I see.


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

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

[Jeffrey A Law]

  In message < m10BoHn-000392C@ocean.lucon.org >you write:
  > > 
  > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
  > ing
  > > > concrete yet.
  > > 
  > > I think the minimal solution is to make initializer symbols static on
  > > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > > whether it does what it promises to do.
  > 
  > I am only interested in Linux. If we really cannot fix the problem for
  > all platforms, it is ok with me as long as Linux is ok :-(.
That may be your only concern, but this project is not just a linux compiler.
We have to think about broader scopes than just linux.



jeff

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

[H.J. Lu]

> 
> 
>   In message < m10BoHn-000392C@ocean.lucon.org >you write:
>   > > 
>   > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
>   > ing
>   > > > concrete yet.
>   > > 
>   > > I think the minimal solution is to make initializer symbols static on
>   > > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > > whether it does what it promises to do.
>   > 
>   > I am only interested in Linux. If we really cannot fix the problem for
>   > all platforms, it is ok with me as long as Linux is ok :-(.
> That may be your only concern, but this project is not just a linux compiler.
> We have to think about broader scopes than just linux.
> 

It is a very hard problem. It may not have solutons for all platforms.
But it doesn't mean we should not fix those we can fix.


H.J.

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

[Jeffrey A Law]

  In message < m10Boh4-000392C@ocean.lucon.org >you write:
  > It is a very hard problem. It may not have solutons for all platforms.
  > But it doesn't mean we should not fix those we can fix.
But it also doesn't mean we take the stance of fixing linux and ignoring
everything else.

Furthermore, this is an ABI/API change, we want to be very careful making
such changes.

jeff

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

[H.J. Lu]

> 
> 
> 
>   In message < m10Boh4-000392C@ocean.lucon.org >you write:
>   > It is a very hard problem. It may not have solutons for all platforms.
>   > But it doesn't mean we should not fix those we can fix.
> But it also doesn't mean we take the stance of fixing linux and ignoring
> everything else.
> 

Here is my proposal. main () in toplev.c calls unique_string () to
initialize a static variable in tree.c:

static char *file_function_name_base;

with

	file_function_name_base = unique_string ();

We also add a counter in tree.c:

static int file_function_name_counter;

get_file_function_name in tree.c will create a file funtcion name with

	file_function_name = file_function_name_base
			     + main_input_filename
			     + file_function_name_counter;

This way we can say with quite confidence that file_function_name will
be unique across all machines in the world for a given OS on a given
arch if they are configured properly. Of course, it may not work for
all OSes. But it should cover most if not all Unix-alike systems.

> Furthermore, this is an ABI/API change, we want to be very careful making
> such changes.
> 

I am not sure if the ABI/API change caused by making global ctors/dtors
static is visible to user. At least, it should be safe on ELF systems.


-- 
H.J. Lu (hjl@gnu.org)
---
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#if defined HAVE_SYS_UTSNAME_H && defined HAVE_UNAME
#include <sys/utsname.h>
#endif

#if defined HAVE_TIME_H && defined HAVE_STRFTIME \
    && defined HAVE_GMTIME && defined HAVE_TIME
#include <time.h>
#endif

#define xmalloc	malloc

#define is_valid_symbol_char(c) \
  ((c) == '_' || (c) == '.' || ((c) >= '0' && (c) <= '9') \
   || ((c) >= 'a' && (c) <= 'z') || ((c) >= 'A' && (c) <= 'Z'))

char *
unique_string ()
{
  char *domainname = NULL;
  char *hostname = NULL;
  char *sysname = NULL;
  char *release = NULL;
  char *version = NULL;
  char *machine = NULL;
  char current_time [] = "yyyymmddhhmmss";
  long pid = getpid ();
  char *unique_name;
  int len;

#ifdef HAVE_GETDOMAINNAME
  {
    len = 0;
    do
      {
	len += 128;
	domainname = (char *) alloca (len);
	if (getdomainname (domainname, len) == 0)
	  break;
	else
	  domainname = NULL;
      }
    while (len < 512);
  }
#endif

#ifdef HAVE_GETHOSTNAME
  {
    len = 0;
    do
      {
	len += 128;
	hostname = (char *) alloca (len);
	if (gethostname (hostname, len) == 0)
	  break;
	else
	  hostname = NULL;
      }
    while (len < 512);
  }
#endif

#if defined HAVE_UNAME && defined HAVE_SYS_UTSNAME_H
  {
    struct utsname utsname;

    if (uname (&utsname) == 0)
      {
#ifdef HAVE_DOMAINNAME_IN_UTSNAME
        if (!domainname)
	  domainname = utsname.domainname;
#endif
#ifdef HAVE_NODENAME_IN_UTSNAME
        if (!hostname)
	  hostname = utsname.nodename;
#endif
#ifdef HAVE_SYSNAME_IN_UTSNAME
	sysname = utsname.sysname;
#endif
#ifdef HAVE_RELEASE_IN_UTSNAME
	release = utsname.release;
#endif
#ifdef HAVE_VERSION_IN_UTSNAME
	version = utsname.version;
#endif
#ifdef HAVE_MACHINE_IN_UTSNAME
	machine = utsname.machine;
#endif
      }
  }
#endif

  if (!domainname || *domainname == '\0')
    domainname = "localdomain";

  if (!hostname || *hostname == '\0')
    hostname = "localhost";

  if (!sysname || *sysname == '\0')
    sysname = "UnknownOS";

  if (!release || *release == '\0')
    release = "UnknownRelease";

  if (!version || *version == '\0')
    version = "UnknownVersion";

  if (!machine || *machine == '\0')
    machine = "UnknownMachine";

#if defined HAVE_STRFTIME && defined HAVE_GMTIME && defined HAVE_TIME
  {
    time_t t;
    
    t = time (NULL);
    if (strftime (current_time, sizeof (current_time),
    		  "%Y%m%d%H%M%S", gmtime (&t)) == 0)
      strcpy (current_time, "yyyymmddhhmmss");
  }
#endif

  {
    char *dot = strchr (hostname, '.');

    if (!dot || strchr (++dot, '.') == NULL)
      {
        /* There are no 2 dots in hostname. We need to append the
	   domainname. */
	len = 1 + strlen (hostname) + 1 + strlen (domainname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s.%s%s%s%s%s%s%.8x",
		 hostname, domainname, sysname, release, version,
		 machine, current_time, pid);
      }
    else
      {
	len = 1 + strlen (hostname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s%s%s%s%s%s%.8x",
		 hostname, sysname, release, version,
		 machine, current_time, pid);
      }
  }

  {
    int i;

    for (i = 1; i < len - 1 - sizeof (current_time) - 8; i++)
      {
        if (!is_valid_symbol_char (unique_name [i]))
	  unique_name [i] = '_';
      }
  }
  return unique_name;
}

main ()
{
  printf ("%s\n", unique_string ());
}

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

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> Here is my proposal. main () in toplev.c calls unique_string ()
    H> to initialize a static variable in tree.c:

In my opinion, this is not a good proposal.  In another life, I work
on issues of computer security, and silently putting things that might
reveal the hostname where the program is compiled in .o files is not
at all a good thing.

If we can make the functions static, the problem goes away, right?  If
not, then sufficiently many random bits is just fine.  I would guess
that 2048 would be more than enough for quite some time to come.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

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

[H.J. Lu]

> 
> >>>>> "H" == H J Lu <hjl@lucon.org> writes:
> 
>     H> Here is my proposal. main () in toplev.c calls unique_string ()
>     H> to initialize a static variable in tree.c:
> 
> In my opinion, this is not a good proposal.  In another life, I work
> on issues of computer security, and silently putting things that might
> reveal the hostname where the program is compiled in .o files is not
> at all a good thing.

I see. How about removing hostname and domainname?

> 
> If we can make the functions static, the problem goes away, right?  If
> not, then sufficiently many random bits is just fine.  I would guess
> that 2048 would be more than enough for quite some time to come.
> 

For anonymouse namspace, they are global. I don't think random bits
alone are any better than timestamp. How about timestamp + random bits?


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

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

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> I see. How about removing hostname and domainname?

Better.

    >>  If we can make the functions static, the problem goes away,
    >> right?  If not, then sufficiently many random bits is just
    >> fine.  I would guess that 2048 would be more than enough for
    >> quite some time to come.
    >> 

    H> For anonymouse namspace, they are global. I don't think random
    H> bits alone are any better than timestamp. How about timestamp +
    H> random bits?

Sure, that's fine.  But, why bother?  Random bits are very, very good.
Anything is else is an unnecessary complication.  Using more random
bits is easier that throwing in any other attempted uniquifications.

We just need a pile of bits.  If I were you, I'd seed the random
number generator with a hash of timestamp + pid + ip address, and call
it good enough.  These are all 32-bit values, on many machines, so you
can just XOR them.  On other hosts, concatenate.  It doesn't really
matter much.  Of course, this doesn't guarantee uniqueness; multiple
machines can have the same IP address.  (Especially, 192.168.x.x).
But, it should be good enough.  You could use autoconf to see if
there's a /dev/random and use that instead of the pseudo-random number
generator, if available.  Then, you don't even have to seed.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

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

[Kamil Iskra]

On Mon, 15 Feb 1999, Mark Mitchell wrote:

> We just need a pile of bits.
[snip]
> You could use autoconf to see if
> there's a /dev/random and use that instead of the pseudo-random number
> generator, if available.  Then, you don't even have to seed.

Erm, don't you perhaps mean /dev/urandom? With /dev/random, compiler could
easily use all the random numbers in kernel buffer and than would have to
wait until new ones are generated. That would be fun: one would have to
press some keys on the keyboard or ping the machine in order for the
compiler to do its job :-).

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

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

[Zack Weinberg]

On Wed, 17 Feb 1999 22:19:25 +0100 (EET), Kamil Iskra wrote:
>On Mon, 15 Feb 1999, Mark Mitchell wrote:
>
>> We just need a pile of bits.
>[snip]
>> You could use autoconf to see if
>> there's a /dev/random and use that instead of the pseudo-random number
>> generator, if available.  Then, you don't even have to seed.
>
>Erm, don't you perhaps mean /dev/urandom?

I think all this stuff is overkill.  For ELF (and XCOFF, ROSE, etc), we
localize the symbols, problem solved.  For a.out and other limited
formats, take a hash of the absolute path and the hostname, that will
be unique enough - if you're worried about exposing info, make it
cryptographically strong.

zw

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

[Zack Weinberg]

On Wed, 17 Feb 1999 22:19:25 +0100 (EET), Kamil Iskra wrote:
>On Mon, 15 Feb 1999, Mark Mitchell wrote:
>
>> We just need a pile of bits.
>[snip]
>> You could use autoconf to see if
>> there's a /dev/random and use that instead of the pseudo-random number
>> generator, if available.  Then, you don't even have to seed.
>
>Erm, don't you perhaps mean /dev/urandom?

I think all this stuff is overkill.  For ELF (and XCOFF, ROSE, etc), we
localize the symbols, problem solved.  For a.out and other limited
formats, take a hash of the absolute path and the hostname, that will
be unique enough - if you're worried about exposing info, make it
cryptographically strong.

zw

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

[Kamil Iskra]

On Mon, 15 Feb 1999, Mark Mitchell wrote:

> We just need a pile of bits.
[snip]
> You could use autoconf to see if
> there's a /dev/random and use that instead of the pseudo-random number
> generator, if available.  Then, you don't even have to seed.

Erm, don't you perhaps mean /dev/urandom? With /dev/random, compiler could
easily use all the random numbers in kernel buffer and than would have to
wait until new ones are generated. That would be fun: one would have to
press some keys on the keyboard or ping the machine in order for the
compiler to do its job :-).

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

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

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> I see. How about removing hostname and domainname?

Better.

    >>  If we can make the functions static, the problem goes away,
    >> right?  If not, then sufficiently many random bits is just
    >> fine.  I would guess that 2048 would be more than enough for
    >> quite some time to come.
    >> 

    H> For anonymouse namspace, they are global. I don't think random
    H> bits alone are any better than timestamp. How about timestamp +
    H> random bits?

Sure, that's fine.  But, why bother?  Random bits are very, very good.
Anything is else is an unnecessary complication.  Using more random
bits is easier that throwing in any other attempted uniquifications.

We just need a pile of bits.  If I were you, I'd seed the random
number generator with a hash of timestamp + pid + ip address, and call
it good enough.  These are all 32-bit values, on many machines, so you
can just XOR them.  On other hosts, concatenate.  It doesn't really
matter much.  Of course, this doesn't guarantee uniqueness; multiple
machines can have the same IP address.  (Especially, 192.168.x.x).
But, it should be good enough.  You could use autoconf to see if
there's a /dev/random and use that instead of the pseudo-random number
generator, if available.  Then, you don't even have to seed.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

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

[Jason Merrill]

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

>>>>> "H" == H J Lu <hjl@lucon.org> writes:
 H> I see. How about removing hostname and domainname?

 H> For anonymouse namspace, they are global. I don't think random
 H> bits alone are any better than timestamp. How about timestamp +
 H> random bits?

 > Sure, that's fine.  But, why bother?  Random bits are very, very good.
 > Anything is else is an unnecessary complication.  Using more random
 > bits is easier that throwing in any other attempted uniquifications.

 > We just need a pile of bits.  If I were you, I'd seed the random
 > number generator with a hash of timestamp + pid + ip address, and call
 > it good enough.

The current code uses timestamp ^ pid directly, without going through the
random number generator.  The code was lifted from mkstemp in libiberty.

Really, this seems entirely adequate to me.  The number of translation
units that actually rely on this is small; witness how long it took to fix
this problem in the first place.

Jason

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

[Mark Mitchell]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:


    Jason> The current code uses timestamp ^ pid directly, without
    Jason> going through the random number generator.  The code was
    Jason> lifted from mkstemp in libiberty.

    Jason> Really, this seems entirely adequate to me.  The number of
    Jason> translation units that actually rely on this is small;
    Jason> witness how long it took to fix this problem in the first
    Jason> place.

Probably the current approach *is* good enough.  I was operating under
the assumption that it wasn't, since HJ was concerned about it.  So, I
stand by my assertion that the right way to fix it, if it needs
fixing, is to add some random bits.  Of course, if ain't even broke,
then just leaving it be is fine, too!

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

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

[Steinar Bang]

>>>>> Mark Mitchell <mark@markmitchell.com>:

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

Jason> The current code uses timestamp ^ pid directly, without going
Jason> through the random number generator.  The code was lifted from
Jason> mkstemp in libiberty.

Jason> Really, this seems entirely adequate to me.  The number of
Jason> translation units that actually rely on this is small; witness
Jason> how long it took to fix this problem in the first place.

> Probably the current approach *is* good enough.  I was operating
> under the assumption that it wasn't, since HJ was concerned about
> it.

If this is the approach 1.1.1 uses on the thing that started this
thread (I'm not sure of I'm following the current discussion), this
test case will break it on linux:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

If the approach Jason lists above is the cause, the approach does not
seem adequate to me.  

What I'm doing in the real cause (not the test case) is putting self
registering singletons in .so files, and having them register
temselves with a central registry when the .so files are loaded (the
constructor of the singleton does the registration, and we create a
static instance of each singleton).

I don't think this is a particularily exotic thing to do.  It seemed
like a good, clean way to implement run-time loadable modules.

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

[Steinar Bang]

>>>>> Mark Mitchell <mark@markmitchell.com>:

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

Jason> The current code uses timestamp ^ pid directly, without going
Jason> through the random number generator.  The code was lifted from
Jason> mkstemp in libiberty.

Jason> Really, this seems entirely adequate to me.  The number of
Jason> translation units that actually rely on this is small; witness
Jason> how long it took to fix this problem in the first place.

> Probably the current approach *is* good enough.  I was operating
> under the assumption that it wasn't, since HJ was concerned about
> it.

If this is the approach 1.1.1 uses on the thing that started this
thread (I'm not sure of I'm following the current discussion), this
test case will break it on linux:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

If the approach Jason lists above is the cause, the approach does not
seem adequate to me.  

What I'm doing in the real cause (not the test case) is putting self
registering singletons in .so files, and having them register
temselves with a central registry when the .so files are loaded (the
constructor of the singleton does the registration, and we create a
static instance of each singleton).

I don't think this is a particularily exotic thing to do.  It seemed
like a good, clean way to implement run-time loadable modules.

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

[Mark Mitchell]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:


    Jason> The current code uses timestamp ^ pid directly, without
    Jason> going through the random number generator.  The code was
    Jason> lifted from mkstemp in libiberty.

    Jason> Really, this seems entirely adequate to me.  The number of
    Jason> translation units that actually rely on this is small;
    Jason> witness how long it took to fix this problem in the first
    Jason> place.

Probably the current approach *is* good enough.  I was operating under
the assumption that it wasn't, since HJ was concerned about it.  So, I
stand by my assertion that the right way to fix it, if it needs
fixing, is to add some random bits.  Of course, if ain't even broke,
then just leaving it be is fine, too!

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

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

[Jeffrey A Law]

  In message < u9ww1ii3mw.fsf@yorick.cygnus.com >you write:
  > The current code uses timestamp ^ pid directly, without going through the
  > random number generator.  The code was lifted from mkstemp in libiberty.
  > 
  > Really, this seems entirely adequate to me.  The number of translation
  > units that actually rely on this is small; witness how long it took to fix
  > this problem in the first place.
timestamp ^ pid seems quite reasonable to me too.  It's not 100% perfect, but
it is good enough IMHO.

So, what changes do I need to pull into egcs-1.1.2?

jeff

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
 > perfect, but it is good enough IMHO.

 > So, what changes do I need to pull into egcs-1.1.2?

Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>

        * tree.c (append_random_chars): New fn.
        (get_file_function_name_long): Use it.

It will need to be massaged a bit because 1.1.x doesn't have the change for
get_file_function_name_long, but that's not important.

Jason

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

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
>  > perfect, but it is good enough IMHO.
> 
>  > So, what changes do I need to pull into egcs-1.1.2?
> 
> Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * tree.c (append_random_chars): New fn.
>         (get_file_function_name_long): Use it.
> 
> It will need to be massaged a bit because 1.1.x doesn't have the change for
> get_file_function_name_long, but that's not important.
> 
> Jason

No matter what you use, please make sure ctors/dtors are local on
ELF.

Thanks.


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

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

[Jeffrey A Law]

  In message < m10D8I7-00038sC@ocean.lucon.org >you write:
  > > 
  > > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
  > > 
  > >  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
  > >  > perfect, but it is good enough IMHO.
  > > 
  > >  > So, what changes do I need to pull into egcs-1.1.2?
  > > 
  > > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > > 
  > >         * tree.c (append_random_chars): New fn.
  > >         (get_file_function_name_long): Use it.
  > > 
  > > It will need to be massaged a bit because 1.1.x doesn't have the change f
  > or
  > > get_file_function_name_long, but that's not important.
  > > 
  > > Jason
  > 
  > No matter what you use, please make sure ctors/dtors are local on
  > ELF.
Why is this necessary if we use Jason's patch?

jeff

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:

 >> No matter what you use, please make sure ctors/dtors are local on
 >> ELF.

 > Why is this necessary if we use Jason's patch?

It isn't, but it doesn't hurt, either.  I don't see any need for it in
1.1.2, though.

Jason

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

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:
> 
>  >> No matter what you use, please make sure ctors/dtors are local on
>  >> ELF.
> 
>  > Why is this necessary if we use Jason's patch?
> 
> It isn't, but it doesn't hurt, either.  I don't see any need for it in
> 1.1.2, though.
> 

You got it backward. Making ctors/dtors local on ELF FIXES the bug on
ELF. However, your patch won't hurt.

BTW, as far as file scope ctors/dtors on ELF are concerned, your patch
is not as good as making them local. This change will be in egcs
1.1.2/Linux.

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

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

[Jeffrey A Law]

  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > ELF. However, your patch won't hurt.
Yours works by introducing an ELF specific hack.

Jason's patch, while not 100% correct either is a lot closer than yours since
it works for a large number of targets instead of just ELF.  The cases where
it fails should be minimial as far as I can tell.

HJ, remember, we care about more than just Linux and ELF.  We have to.



jeff

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

[H.J. Lu]

> 
> 
>   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > ELF. However, your patch won't hurt.
> Yours works by introducing an ELF specific hack.
> 
> Jason's patch, while not 100% correct either is a lot closer than yours since

Mine is 100% correct on ELF.

> it works for a large number of targets instead of just ELF.  The cases where
> it fails should be minimial as far as I can tell.
> 
> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

That is fine. But why cannot we have both? That way, ELF will be 100%
correct and others will be almost correct? For me, this discussion
makes few difference. I will make ELF 100% safe for Linux in anycase.

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

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

[Jeffrey A Law]

  In message < m10EJQj-000392C@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > >   > ELF. However, your patch won't hurt.
  > > Yours works by introducing an ELF specific hack.
  > > 
  > > Jason's patch, while not 100% correct either is a lot closer than yours s
  > ince
  > 
  > Mine is 100% correct on ELF.
And totally useless everywhere else.


  > That is fine. But why cannot we have both? That way, ELF will be 100%
  > correct and others will be almost correct? For me, this discussion
  > makes few difference. I will make ELF 100% safe for Linux in anycase.
Send me a patch and I'll consider it.  I will not accept a hack.



jeff

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

[H.J. Lu]

> 
> 
>   In message < m10EJQj-000392C@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > >   > ELF. However, your patch won't hurt.
>   > > Yours works by introducing an ELF specific hack.
>   > > 
>   > > Jason's patch, while not 100% correct either is a lot closer than yours s
>   > ince
>   > 
>   > Mine is 100% correct on ELF.
> And totally useless everywhere else.
> 

I won't go that far.

> 
>   > That is fine. But why cannot we have both? That way, ELF will be 100%
>   > correct and others will be almost correct? For me, this discussion
>   > makes few difference. I will make ELF 100% safe for Linux in anycase.
> Send me a patch and I'll consider it.  I will not accept a hack.
> 
> 
> 

Here it is.

-- 
H.J. Lu (hjl@gnu.org)
----
Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)

        * decl2.c (start_objects): Make file scope constructors and
        destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
        ASM_OUTPUT_DESTRUCTOR are defined.

--- ../../../../import/egcs/gcc/cp/decl2.c	Tue Nov 10 07:44:01 1998
+++ decl2.c	Sat Feb 20 11:32:58 1999
@@ -2943,6 +2943,11 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
+  /* It can be a static function with .ctors/.dtors sections. */
+  TREE_PUBLIC (current_function_decl) = 0;
+#endif
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();

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

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > Here it is.
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
I don't think this patch is correct.

Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
that this patch wil work on COFF systems?





jeff

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

[H.J. Lu]

> 
> 
>   In message < m10EJXX-000392C@ocean.lucon.org >you write:
>   > Here it is.
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ----
>   > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   >         * decl2.c (start_objects): Make file scope constructors and
>   >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>   >         ASM_OUTPUT_DESTRUCTOR are defined.
> I don't think this patch is correct.
> 
> Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
> that this patch wil work on COFF systems?
> 

I know next to nothing about COFF and I have no access to any COFF
systems. I guess it is not hard to try it on a COFF system.

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

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

[H.J. Lu]

> 
> 
>   In message < m10EJXX-000392C@ocean.lucon.org >you write:
>   > Here it is.
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ----
>   > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   >         * decl2.c (start_objects): Make file scope constructors and
>   >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>   >         ASM_OUTPUT_DESTRUCTOR are defined.
> I don't think this patch is correct.
> 
> Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
> that this patch wil work on COFF systems?
> 

I know next to nothing about COFF and I have no access to any COFF
systems. I guess it is not hard to try it on a COFF system.

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

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

[Jeffrey A Law]

  In message < m10EJh1-000392C@ocean.lucon.org >you write:
  > > Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
  > > that this patch wil work on COFF systems?
  > > 
  > 
  > I know next to nothing about COFF and I have no access to any COFF
  > systems. I guess it is not hard to try it on a COFF system.
Which is precisely why this kind of patch is terribly dangerous and IMHO, not
really suitable for a minor release like egcs-1.1.2.

Will someone please test this patch on some COFF systems.

It absolutely can not and will not go in if we can not verify it does the
correct thing on COFF systems.



jeff

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

[Robert Lipe]

>   > > Consider COFF systems which define ASM_OUTPUT_*.  Are you
>   > > absolutely sure that this patch wil work on COFF systems?
>   >
>   > I know next to nothing about COFF and I have no access to any COFF
>   > systems. I guess it is not hard to try it on a COFF system.
>
> Will someone please test this patch on some COFF systems.

I have ready access to an x86 COFF system.  OpenServer is both COFF and
ELF which might make it an interesting testsuite.  I should note that
OpenServer's COFF does define a multitude of ASM_OUTPUT_* operators.

If you can reach an agreement on exactly what needs to be tested and can
describe it concisely to me (not necessarily to the list), I'll spin a
bootstrap on one tree of your choosing (release or trunk) and run a set
of tests of your choosing.

Given the contention surrounding the failure modes and testcases, I'm
not about to walk into a battle.  Tell me exactly what you want tested
and I'll return true or false.

Clock cycles I have.   Appetite for a brawl I don't.

RJL

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

[Jeffrey A Law]

  In message < 19990220153254.A8783@rjlhome.sco.com >you write:
  > If you can reach an agreement on exactly what needs to be tested and can
  > describe it concisely to me (not necessarily to the list), I'll spin a
  > bootstrap on one tree of your choosing (release or trunk) and run a set
  > of tests of your choosing.
I think the key is how do ctors/dtors fire for a shared library, both those
which appear on the link line and those which are explicitly loaded during
the execution of the program.

If the dynamic linker is responsible for firing them via .init sections or
similar mechanisms, then OpenServer would probably be fine with HJ's patch.


I'm going to sit down with this testcase from Steinar Bang and HJ's patch
for a few minutes too.  There's a voice inside my head that keeps telling me
I'm missing something with this whole discussion.


	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz


  > Clock cycles I have.   Appetite for a brawl I don't.
Well put.  That's what this is starting to turn into.  Deep breath time.

jeff

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

[Jeffrey A Law]

  In message < 19990220153254.A8783@rjlhome.sco.com >you write:
  > If you can reach an agreement on exactly what needs to be tested and can
  > describe it concisely to me (not necessarily to the list), I'll spin a
  > bootstrap on one tree of your choosing (release or trunk) and run a set
  > of tests of your choosing.
I think the key is how do ctors/dtors fire for a shared library, both those
which appear on the link line and those which are explicitly loaded during
the execution of the program.

If the dynamic linker is responsible for firing them via .init sections or
similar mechanisms, then OpenServer would probably be fine with HJ's patch.


I'm going to sit down with this testcase from Steinar Bang and HJ's patch
for a few minutes too.  There's a voice inside my head that keeps telling me
I'm missing something with this whole discussion.


	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz


  > Clock cycles I have.   Appetite for a brawl I don't.
Well put.  That's what this is starting to turn into.  Deep breath time.

jeff

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

[Robert Lipe]

>   > > Consider COFF systems which define ASM_OUTPUT_*.  Are you
>   > > absolutely sure that this patch wil work on COFF systems?
>   >
>   > I know next to nothing about COFF and I have no access to any COFF
>   > systems. I guess it is not hard to try it on a COFF system.
>
> Will someone please test this patch on some COFF systems.

I have ready access to an x86 COFF system.  OpenServer is both COFF and
ELF which might make it an interesting testsuite.  I should note that
OpenServer's COFF does define a multitude of ASM_OUTPUT_* operators.

If you can reach an agreement on exactly what needs to be tested and can
describe it concisely to me (not necessarily to the list), I'll spin a
bootstrap on one tree of your choosing (release or trunk) and run a set
of tests of your choosing.

Given the contention surrounding the failure modes and testcases, I'm
not about to walk into a battle.  Tell me exactly what you want tested
and I'll return true or false.

Clock cycles I have.   Appetite for a brawl I don't.

RJL

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

[Andris Pavenis]

On Sat, 20 Feb 1999, Jeffrey A Law wrote:
>In message < m10EJXX-000392C@ocean.lucon.org >you write:
>  > Here it is.
>  > 
>  > -- 
>  > H.J. Lu (hjl@gnu.org)
>  > ----
>  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>  > 
>  >         * decl2.c (start_objects): Make file scope constructors and
>  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>  >         ASM_OUTPUT_DESTRUCTOR are defined.
>I don't think this patch is correct.
>
>Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
>that this patch wil work on COFF systems?
>

I tried it for DJGPP (which uses COFF) and initially didn't saw problems.
But anyway some more testing is required.  

Maybe it worth to add one additional macro to enable making file scope
constructors local

#if defined(ASM_OUTPUT_CONSTRUCTOR) && \
    defined(ASM_OUTPUT_DESTRUCTOR) && \
    defined(MAKE_SCOPE_CONSTRUCTORS_LOCAL)

Then we would be able to enable this feature only on systems we want it to 
be enabled.

Andris

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

[Andris Pavenis]

On Sat, 20 Feb 1999, Jeffrey A Law wrote:
>In message < m10EJXX-000392C@ocean.lucon.org >you write:
>  > Here it is.
>  > 
>  > -- 
>  > H.J. Lu (hjl@gnu.org)
>  > ----
>  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>  > 
>  >         * decl2.c (start_objects): Make file scope constructors and
>  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>  >         ASM_OUTPUT_DESTRUCTOR are defined.
>I don't think this patch is correct.
>
>Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
>that this patch wil work on COFF systems?
>

I tried it for DJGPP (which uses COFF) and initially didn't saw problems.
But anyway some more testing is required.  

Maybe it worth to add one additional macro to enable making file scope
constructors local

#if defined(ASM_OUTPUT_CONSTRUCTOR) && \
    defined(ASM_OUTPUT_DESTRUCTOR) && \
    defined(MAKE_SCOPE_CONSTRUCTORS_LOCAL)

Then we would be able to enable this feature only on systems we want it to 
be enabled.

Andris

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

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > Here it is.
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
I don't think this patch is correct.

Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
that this patch wil work on COFF systems?





jeff

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

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
Note this patch also effects Windows/NT and VMS (alpha & dec).

IMHO, it does not belong in egcs-1.1.2.  It's simply too dangerous.

jeff

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

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
Note this patch also effects Windows/NT and VMS (alpha & dec).

IMHO, it does not belong in egcs-1.1.2.  It's simply too dangerous.

jeff

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

[Mumit Khan]

On Sat, 20 Feb 1999, H.J. Lu wrote:

>  
> +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
> +  /* It can be a static function with .ctors/.dtors sections. */
> +  TREE_PUBLIC (current_function_decl) = 0;
> +#endif
> +

Whoa, this affects other systems besides ELF, so let's please be careful!
I know for sure it affects windows32 PE-COFF systems, and possibly all the
other COFF'ish systems as well.

I'll try it out locally to see the effect on windows32, but only on my dev 
branch, not 1.1.2 branch.

Regards,
Mumit

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

[Mumit Khan]

On Sat, 20 Feb 1999, H.J. Lu wrote:

>  
> +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
> +  /* It can be a static function with .ctors/.dtors sections. */
> +  TREE_PUBLIC (current_function_decl) = 0;
> +#endif
> +

Whoa, this affects other systems besides ELF, so let's please be careful!
I know for sure it affects windows32 PE-COFF systems, and possibly all the
other COFF'ish systems as well.

I'll try it out locally to see the effect on windows32, but only on my dev 
branch, not 1.1.2 branch.

Regards,
Mumit

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

[Martin v. Loewis]

>         * decl2.c (start_objects): Make file scope constructors and
>         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>         ASM_OUTPUT_DESTRUCTOR are defined.

This is incorrect. Please look at config/aoutos.h. It always defines
ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
and collect2 would have to find constructors. Now that you made them
static, this would fail.

Regards,
Martin

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

[H.J. Lu]

> 
> >         * decl2.c (start_objects): Make file scope constructors and
> >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
> >         ASM_OUTPUT_DESTRUCTOR are defined.
> 
> This is incorrect. Please look at config/aoutos.h. It always defines
> ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
> GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
> and collect2 would have to find constructors. Now that you made them
> static, this would fail.
> 

That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
to use the gnu linker. Why does config/aoutos.h to have duplicate
what is in the egcs backend?

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

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

[Jeffrey A Law]

  In message < m10EMUB-000392C@ocean.lucon.org >you write:
  > > 
  > > >         * decl2.c (start_objects): Make file scope constructors and
  > > >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  > > >         ASM_OUTPUT_DESTRUCTOR are defined.
  > > 
  > > This is incorrect. Please look at config/aoutos.h. It always defines
  > > ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
  > > GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
  > > and collect2 would have to find constructors. Now that you made them
  > > static, this would fail.
  > > 
  > 
  > That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
  > used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
  > to use the gnu linker. Why does config/aoutos.h to have duplicate
  > what is in the egcs backend?
I think you missed the most critical point behind Martin's objection.

Your change, as-is will break a port.

You need to address this problem in some manner (I think there have been
suggestions posted to the list).

There's still the issue of breaking NT, VMS and a variety of COFF systems
too with your patch.

jeff

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

[Jeffrey A Law]

  In message < m10EMUB-000392C@ocean.lucon.org >you write:
  > > 
  > > >         * decl2.c (start_objects): Make file scope constructors and
  > > >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  > > >         ASM_OUTPUT_DESTRUCTOR are defined.
  > > 
  > > This is incorrect. Please look at config/aoutos.h. It always defines
  > > ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
  > > GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
  > > and collect2 would have to find constructors. Now that you made them
  > > static, this would fail.
  > > 
  > 
  > That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
  > used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
  > to use the gnu linker. Why does config/aoutos.h to have duplicate
  > what is in the egcs backend?
I think you missed the most critical point behind Martin's objection.

Your change, as-is will break a port.

You need to address this problem in some manner (I think there have been
suggestions posted to the list).

There's still the issue of breaking NT, VMS and a variety of COFF systems
too with your patch.

jeff

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

[H.J. Lu]

> 
> >         * decl2.c (start_objects): Make file scope constructors and
> >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
> >         ASM_OUTPUT_DESTRUCTOR are defined.
> 
> This is incorrect. Please look at config/aoutos.h. It always defines
> ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
> GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
> and collect2 would have to find constructors. Now that you made them
> static, this would fail.
> 

That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
to use the gnu linker. Why does config/aoutos.h to have duplicate
what is in the egcs backend?

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

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

[Martin v. Loewis]

>         * decl2.c (start_objects): Make file scope constructors and
>         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>         ASM_OUTPUT_DESTRUCTOR are defined.

This is incorrect. Please look at config/aoutos.h. It always defines
ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
and collect2 would have to find constructors. Now that you made them
static, this would fail.

Regards,
Martin

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

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 > +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
 > +  /* It can be a static function with .ctors/.dtors sections. */
 > +  TREE_PUBLIC (current_function_decl) = 0;
 > +#endif

This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
imply the use of .ctors/.dtors sections.  As someone else mentioned,
aoutos.h defines it to a conditional, though there's really no reason for
that; the code in aoutos.h is a duplicate of the code in
assemble_constructor.  I think this approach will work if we remove the
aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
does not rely on the name being exported, and that it is unconditional.

While we're at it, we should reduce the redundancy of the tm files; there
are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.

Jason

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

[Jeffrey A Law]

  In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  > imply the use of .ctors/.dtors sections.
Right.  That's why trying to if this problem by depending on that macro is
wrong.  

It sounds like we need a new macro which indicates the target uses ctor/dtor
sections and the dynamic linker handles firing of ctors/dtors.  Given such
a macro.

  > As someone else mentioned,
  > aoutos.h defines it to a conditional, though there's really no reason for
  > that; the code in aoutos.h is a duplicate of the code in
  > assemble_constructor.  I think this approach will work if we remove the
  > aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
  > does not rely on the name being exported, and that it is unconditional.
  > 
  > While we're at it, we should reduce the redundancy of the tm files; there
  > are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.
Yea.  But fixing aoutos.h does not (IMHO) make HJ's patch correct since it
really sounds like he's depending on the wrong macro to control the behavior
he wants.

I'll fix aoutos.h in the mainline tree.


jeff

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

[Jeffrey A Law]

[ replying to my own ill-formed message ]

  In message < 7817.919639310@hurl.cygnus.com > I write:

  >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  >   > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  >   > imply the use of .ctors/.dtors sections.
  > Right.  That's why trying to if this problem by depending on that macro is
  > wrong.  
			         ^^^ fix

  > It sounds like we need a new macro which indicates the target uses
  > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
  > Given such a macro.
Given such a macro, we can safely make these functions static on those systems
where it is safe.

jeff

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

[Jeffrey A Law]

[ replying to my own ill-formed message ]

  In message < 7817.919639310@hurl.cygnus.com > I write:

  >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  >   > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  >   > imply the use of .ctors/.dtors sections.
  > Right.  That's why trying to if this problem by depending on that macro is
  > wrong.  
			         ^^^ fix

  > It sounds like we need a new macro which indicates the target uses
  > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
  > Given such a macro.
Given such a macro, we can safely make these functions static on those systems
where it is safe.

jeff

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
 >> This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
 >> imply the use of .ctors/.dtors sections.

 > Right.  That's why trying to fix this problem by depending on that macro
 > is wrong.

 > It sounds like we need a new macro which indicates the target uses
 > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
 > Given such a macro, we can safely make these functions static on those
 > systems where it is safe.

I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
documentation; it looks like the aoutos.h version was the only one that
would break with HJ's patch.  All the definitions for COFF and such
targets looked fine; they also rely on the value of the symbol within the
translation unit rather than having it available to the linker.  We only
need the symbols to be public if we're using collect.

Having another macro would also be fine, and would allow for runtime
selection.

Jason

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

[Jeffrey A Law]

  In message < u9lnhrfg3k.fsf@yorick.cygnus.com >you write:
  > I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
  > documentation; it looks like the aoutos.h version was the only one that
  > would break with HJ's patch. 

  > All the definitions for COFF and such
  > targets looked fine; they also rely on the value of the symbol within the
  > translation unit rather than having it available to the linker.  We only
  > need the symbols to be public if we're using collect.
Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

A private discussion with Robert Lipe leads me to believe the change is
OK for SCO and its close relatives.  I haven't a clue about other COFF targets.


  > Having another macro would also be fine, and would allow for runtime
  > selection.
Well, if we can easily make the existing macro safe, I'm all for that.

jeff

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

[Richard Henderson]

On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
> Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

Yes.  Except for that one aout anomaly, they all work by placing a
pointer in a section.  We should always be able to make the symbol
referenced by that pointer local.


r~

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

[Jeffrey A Law]

  In message < 19990221170738.A22156@cygnus.com >you write:
  > On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
  > > Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTO
  > R?
  > 
  > Yes.  Except for that one aout anomaly, they all work by placing a
  > pointer in a section.  We should always be able to make the symbol
  > referenced by that pointer local.
OK.  So we fix aoutos.h apply HJ's patch, & update the docs.  This fixes
ELF & COFF.

Then we backport Jason's October changes to add random chars to mitigate
these problems on other platforms.

Then we can close this issue right?

jeff

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

[Jeffrey A Law]

  In message < 19990221170738.A22156@cygnus.com >you write:
  > On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
  > > Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTO
  > R?
  > 
  > Yes.  Except for that one aout anomaly, they all work by placing a
  > pointer in a section.  We should always be able to make the symbol
  > referenced by that pointer local.
OK.  So we fix aoutos.h apply HJ's patch, & update the docs.  This fixes
ELF & COFF.

Then we backport Jason's October changes to add random chars to mitigate
these problems on other platforms.

Then we can close this issue right?

jeff

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

[Richard Henderson]

On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
> Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

Yes.  Except for that one aout anomaly, they all work by placing a
pointer in a section.  We should always be able to make the symbol
referenced by that pointer local.


r~

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

[Jeffrey A Law]

  In message < u9lnhrfg3k.fsf@yorick.cygnus.com >you write:
  > I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
  > documentation; it looks like the aoutos.h version was the only one that
  > would break with HJ's patch. 

  > All the definitions for COFF and such
  > targets looked fine; they also rely on the value of the symbol within the
  > translation unit rather than having it available to the linker.  We only
  > need the symbols to be public if we're using collect.
Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

A private discussion with Robert Lipe leads me to believe the change is
OK for SCO and its close relatives.  I haven't a clue about other COFF targets.


  > Having another macro would also be fine, and would allow for runtime
  > selection.
Well, if we can easily make the existing macro safe, I'm all for that.

jeff

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
 >> This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
 >> imply the use of .ctors/.dtors sections.

 > Right.  That's why trying to fix this problem by depending on that macro
 > is wrong.

 > It sounds like we need a new macro which indicates the target uses
 > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
 > Given such a macro, we can safely make these functions static on those
 > systems where it is safe.

I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
documentation; it looks like the aoutos.h version was the only one that
would break with HJ's patch.  All the definitions for COFF and such
targets looked fine; they also rely on the value of the symbol within the
translation unit rather than having it available to the linker.  We only
need the symbols to be public if we're using collect.

Having another macro would also be fine, and would allow for runtime
selection.

Jason

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

[Jeffrey A Law]

  In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  > imply the use of .ctors/.dtors sections.
Right.  That's why trying to if this problem by depending on that macro is
wrong.  

It sounds like we need a new macro which indicates the target uses ctor/dtor
sections and the dynamic linker handles firing of ctors/dtors.  Given such
a macro.

  > As someone else mentioned,
  > aoutos.h defines it to a conditional, though there's really no reason for
  > that; the code in aoutos.h is a duplicate of the code in
  > assemble_constructor.  I think this approach will work if we remove the
  > aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
  > does not rely on the name being exported, and that it is unconditional.
  > 
  > While we're at it, we should reduce the redundancy of the tm files; there
  > are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.
Yea.  But fixing aoutos.h does not (IMHO) make HJ's patch correct since it
really sounds like he's depending on the wrong macro to control the behavior
he wants.

I'll fix aoutos.h in the mainline tree.


jeff

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

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 > +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
 > +  /* It can be a static function with .ctors/.dtors sections. */
 > +  TREE_PUBLIC (current_function_decl) = 0;
 > +#endif

This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
imply the use of .ctors/.dtors sections.  As someone else mentioned,
aoutos.h defines it to a conditional, though there's really no reason for
that; the code in aoutos.h is a duplicate of the code in
assemble_constructor.  I think this approach will work if we remove the
aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
does not rely on the name being exported, and that it is unconditional.

While we're at it, we should reduce the redundancy of the tm files; there
are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.

Jason

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

[H.J. Lu]

> 
> 
>   In message < m10EJQj-000392C@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > >   > ELF. However, your patch won't hurt.
>   > > Yours works by introducing an ELF specific hack.
>   > > 
>   > > Jason's patch, while not 100% correct either is a lot closer than yours s
>   > ince
>   > 
>   > Mine is 100% correct on ELF.
> And totally useless everywhere else.
> 

I won't go that far.

> 
>   > That is fine. But why cannot we have both? That way, ELF will be 100%
>   > correct and others will be almost correct? For me, this discussion
>   > makes few difference. I will make ELF 100% safe for Linux in anycase.
> Send me a patch and I'll consider it.  I will not accept a hack.
> 
> 
> 

Here it is.

-- 
H.J. Lu (hjl@gnu.org)
----
Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)

        * decl2.c (start_objects): Make file scope constructors and
        destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
        ASM_OUTPUT_DESTRUCTOR are defined.

--- ../../../../import/egcs/gcc/cp/decl2.c	Tue Nov 10 07:44:01 1998
+++ decl2.c	Sat Feb 20 11:32:58 1999
@@ -2943,6 +2943,11 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
+  /* It can be a static function with .ctors/.dtors sections. */
+  TREE_PUBLIC (current_function_decl) = 0;
+#endif
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();

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

[Jeffrey A Law]

  In message < m10EJQj-000392C@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > >   > ELF. However, your patch won't hurt.
  > > Yours works by introducing an ELF specific hack.
  > > 
  > > Jason's patch, while not 100% correct either is a lot closer than yours s
  > ince
  > 
  > Mine is 100% correct on ELF.
And totally useless everywhere else.


  > That is fine. But why cannot we have both? That way, ELF will be 100%
  > correct and others will be almost correct? For me, this discussion
  > makes few difference. I will make ELF 100% safe for Linux in anycase.
Send me a patch and I'll consider it.  I will not accept a hack.



jeff

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

[H.J. Lu]

> 
> 
>   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > ELF. However, your patch won't hurt.
> Yours works by introducing an ELF specific hack.
> 
> Jason's patch, while not 100% correct either is a lot closer than yours since

Mine is 100% correct on ELF.

> it works for a large number of targets instead of just ELF.  The cases where
> it fails should be minimial as far as I can tell.
> 
> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

That is fine. But why cannot we have both? That way, ELF will be 100%
correct and others will be almost correct? For me, this discussion
makes few difference. I will make ELF 100% safe for Linux in anycase.

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

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

[H.J. Lu]

> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
There is no excuse not to make it 100% correct on Linux if we can.

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

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

[Jeffrey A Law]

  In message < m10EJTY-000392C@ocean.lucon.org >you write:
  > > HJ, remember, we care about more than just Linux and ELF.  We have to.
  > > 
  > 
  > Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
  > There is no excuse not to make it 100% correct on Linux if we can.
There is NO excuse for a hack.  Period.  I will not install a hack.  Period.

If you submit a clean patch I will consider it.

Every release we go through this with one of your pet patches.  And
consistently we find that your "this must go into this release" patch is
bogus, either because it is a hack or because it really doesn't solve the
problem.

Thus, I will not commit to installing your change until I actually see it.

Submit a patch and I will consider it.  Otherwise, stop wasting my time.


jeff

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

[H.J. Lu]

> Thus, I will not commit to installing your change until I actually see it.
> 

Just for the record, The patch I sent out today is the same as

http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

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

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

[Martin v. Loewis]

> Just for the record, The patch I sent out today is the same as
> 
> http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

Unfortunately, it is as incorrect today as it was then.

Martin

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

[Martin v. Loewis]

> Just for the record, The patch I sent out today is the same as
> 
> http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

Unfortunately, it is as incorrect today as it was then.

Martin

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

[H.J. Lu]

> Thus, I will not commit to installing your change until I actually see it.
> 

Just for the record, The patch I sent out today is the same as

http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

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

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

[Jeffrey A Law]

  In message < m10EJTY-000392C@ocean.lucon.org >you write:
  > > HJ, remember, we care about more than just Linux and ELF.  We have to.
  > > 
  > 
  > Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
  > There is no excuse not to make it 100% correct on Linux if we can.
There is NO excuse for a hack.  Period.  I will not install a hack.  Period.

If you submit a clean patch I will consider it.

Every release we go through this with one of your pet patches.  And
consistently we find that your "this must go into this release" patch is
bogus, either because it is a hack or because it really doesn't solve the
problem.

Thus, I will not commit to installing your change until I actually see it.

Submit a patch and I will consider it.  Otherwise, stop wasting my time.


jeff

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

[H.J. Lu]

> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
There is no excuse not to make it 100% correct on Linux if we can.

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

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

[Zack Weinberg]

On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>
>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>  > ELF. However, your patch won't hurt.
>Yours works by introducing an ELF specific hack.
>
>Jason's patch, while not 100% correct either is a lot closer than yours since
>it works for a large number of targets instead of just ELF.  The cases where
>it fails should be minimial as far as I can tell.
>
>HJ, remember, we care about more than just Linux and ELF.  We have to.

I don't really see using local symbols for constructors as an
ELF-specific hack.  HJ's implementation may be ELF-specific, but we
ought to be able to use the same tactic on any system with named
sections - at least XCOFF, and I know there are others.

zw

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

[Jeffrey A Law]

  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
  > I don't really see using local symbols for constructors as an
  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
  > ought to be able to use the same tactic on any system with named
  > sections - at least XCOFF, and I know there are others.
Huh?  Just because a target has named sections does not mean it has functional
init/fini support.  Doesn't making the ctors/dtors static depend on functional
init/fini support, particularly for shared libraries?

jeff

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

[Zack Weinberg]

On Sat, 20 Feb 1999 14:27:02 -0700, Jeffrey A Law wrote:
>
>  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
>  > I don't really see using local symbols for constructors as an
>  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>  > ought to be able to use the same tactic on any system with named
>  > sections - at least XCOFF, and I know there are others.
>Huh?  Just because a target has named sections does not mean it has functional
>init/fini support.  Doesn't making the ctors/dtors static depend on functional
>init/fini support, particularly for shared libraries?

Yes, but I thought that all it takes to have functional init/fini was
named sections and a sensible dynamic linker.  I don't claim to know
this issue inside out, but I do know there used to be plenty of
targets for which basic ctors and dtors would work without collect2,
which meant they had functional init/fini - right?

zw

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

[Jeffrey A Law]

  In message < 199902202135.QAA23017@blastula.phys.columbia.edu >you write:
  > Yes, but I thought that all it takes to have functional init/fini was
  > named sections and a sensible dynamic linker.
Sensible dynamic linker is where some systems start to fall down :(  I know
of at least one where we have named sections, but the dynamic linker support
for initializers and finalizers is too braindamaged to be useful (HPUX).  There
may be others.  For example, I would worry about AIX/XCOFF.

  > I don't claim to know
  > this issue inside out, but I do know there used to be plenty of
  > targets for which basic ctors and dtors would work without collect2,
  > which meant they had functional init/fini - right?
Not necessarily.  Some of those systems worked because the GNU linker did
the collecting instead of collect2.

I believe the GNU linker could either look at the symbol names or magic stabs
(cough cough) to get a list of routines to put in __CTOR_LIST__ and
__DTOR_LIST__.





jeff

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

[Jeffrey A Law]

  In message < 199902202135.QAA23017@blastula.phys.columbia.edu >you write:
  > Yes, but I thought that all it takes to have functional init/fini was
  > named sections and a sensible dynamic linker.
Sensible dynamic linker is where some systems start to fall down :(  I know
of at least one where we have named sections, but the dynamic linker support
for initializers and finalizers is too braindamaged to be useful (HPUX).  There
may be others.  For example, I would worry about AIX/XCOFF.

  > I don't claim to know
  > this issue inside out, but I do know there used to be plenty of
  > targets for which basic ctors and dtors would work without collect2,
  > which meant they had functional init/fini - right?
Not necessarily.  Some of those systems worked because the GNU linker did
the collecting instead of collect2.

I believe the GNU linker could either look at the symbol names or magic stabs
(cough cough) to get a list of routines to put in __CTOR_LIST__ and
__DTOR_LIST__.





jeff

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

[Martin v. Loewis]

> Yes, but I thought that all it takes to have functional init/fini was
> named sections and a sensible dynamic linker.  I don't claim to know
> this issue inside out, but I do know there used to be plenty of
> targets for which basic ctors and dtors would work without collect2,
> which meant they had functional init/fini - right?

Indeed. However, it seems to be non-trivial to find out in gcc whether
we are using such a target.

Regards,
Martin

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

[Kamil Iskra]

On Sun, 21 Feb 1999, Martin v. Loewis wrote:

> > Yes, but I thought that all it takes to have functional init/fini was
> > named sections and a sensible dynamic linker.  I don't claim to know
> > this issue inside out, but I do know there used to be plenty of
> > targets for which basic ctors and dtors would work without collect2,
> > which meant they had functional init/fini - right?
> Indeed. However, it seems to be non-trivial to find out in gcc whether
> we are using such a target.

I don't get it. What's so difficult about introducing a new target macro
that conveys precisely this information?

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

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

[Martin v. Loewis]

> I don't get it. What's so difficult about introducing a new target macro
> that conveys precisely this information?

That is certainly possible. Maybe not for 1.1.2, though...

Regards,
Martin

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

[Martin v. Loewis]

> I don't get it. What's so difficult about introducing a new target macro
> that conveys precisely this information?

That is certainly possible. Maybe not for 1.1.2, though...

Regards,
Martin

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

[Kamil Iskra]

On Sun, 21 Feb 1999, Martin v. Loewis wrote:

> > Yes, but I thought that all it takes to have functional init/fini was
> > named sections and a sensible dynamic linker.  I don't claim to know
> > this issue inside out, but I do know there used to be plenty of
> > targets for which basic ctors and dtors would work without collect2,
> > which meant they had functional init/fini - right?
> Indeed. However, it seems to be non-trivial to find out in gcc whether
> we are using such a target.

I don't get it. What's so difficult about introducing a new target macro
that conveys precisely this information?

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

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

[Martin v. Loewis]

> Yes, but I thought that all it takes to have functional init/fini was
> named sections and a sensible dynamic linker.  I don't claim to know
> this issue inside out, but I do know there used to be plenty of
> targets for which basic ctors and dtors would work without collect2,
> which meant they had functional init/fini - right?

Indeed. However, it seems to be non-trivial to find out in gcc whether
we are using such a target.

Regards,
Martin

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

[Zack Weinberg]

On Sat, 20 Feb 1999 14:27:02 -0700, Jeffrey A Law wrote:
>
>  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
>  > I don't really see using local symbols for constructors as an
>  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>  > ought to be able to use the same tactic on any system with named
>  > sections - at least XCOFF, and I know there are others.
>Huh?  Just because a target has named sections does not mean it has functional
>init/fini support.  Doesn't making the ctors/dtors static depend on functional
>init/fini support, particularly for shared libraries?

Yes, but I thought that all it takes to have functional init/fini was
named sections and a sensible dynamic linker.  I don't claim to know
this issue inside out, but I do know there used to be plenty of
targets for which basic ctors and dtors would work without collect2,
which meant they had functional init/fini - right?

zw

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

[the jackal]

Warning
Could not process message with given Content-Type: 
multipart/signed; boundary=z6Eq5LdranGa6ru8; micalg=pgp-md5;protocol="application/pgp-signature"

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

[Jeffrey A Law]

  In message < 19990221211950.B10271@diwanh.stu.rpi.edu >you write:
  > Jeff et al:
  > 	Is there not a symbol for ELF so as to allow conditional compilation?
  > That way, Mr. Lu's changes may be incorporated under an #ifdef and not
  > effect anything else in the compiler.
No, and adding such a symbol and using it for this test is the wrong approach
to solving this kind of problem.

Instead of saying "it works in ELF", ask yourself the question, what
characteristics of ELF make such a change desirable.

That is how we manage to write a compiler that works across a huge variety of
targets, object file formats, debug formats, host & build systems, etc.


jeff

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

[Jeffrey A Law]

  In message < 19990221211950.B10271@diwanh.stu.rpi.edu >you write:
  > Jeff et al:
  > 	Is there not a symbol for ELF so as to allow conditional compilation?
  > That way, Mr. Lu's changes may be incorporated under an #ifdef and not
  > effect anything else in the compiler.
No, and adding such a symbol and using it for this test is the wrong approach
to solving this kind of problem.

Instead of saying "it works in ELF", ask yourself the question, what
characteristics of ELF make such a change desirable.

That is how we manage to write a compiler that works across a huge variety of
targets, object file formats, debug formats, host & build systems, etc.


jeff

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

[the jackal]

Jeff et al:
	Is there not a symbol for ELF so as to allow conditional compilation? That way, Mr. Lu's changes may be incorporated under an #ifdef and not effect anything else in the compiler.

On Sat, Feb 20, 1999 at 02:27:02PM -0700, Jeffrey A Law wrote:
> Huh?  Just because a target has named sections does not mean it has functional
> init/fini support.  Doesn't making the ctors/dtors static depend on functional
> init/fini support, particularly for shared libraries?

-- 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a

iQCVAwUBNtC+xQ6sg/oMyISxAQFE/wP/SnOabXtbIMQ652H/Oi+ZV48e0LgwnmM5
YHFo+myUyEzn573rzxIfJmMvNzovGR69BOs0pBaiii2+XKZH2RkTMD2gzKsaJ0ym
bRGi05ibkbPE8PG6yNwybd7rwbuwFHg8BVPtigj1OFNQ4Wuux4OBxfJhbLxQ8XTS
GpPmYEx7VGY=
=Lp/U
-----END PGP SIGNATURE-----

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

[Jeffrey A Law]

  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
  > I don't really see using local symbols for constructors as an
  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
  > ought to be able to use the same tactic on any system with named
  > sections - at least XCOFF, and I know there are others.
Huh?  Just because a target has named sections does not mean it has functional
init/fini support.  Doesn't making the ctors/dtors static depend on functional
init/fini support, particularly for shared libraries?

jeff

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

[Andris Pavenis]

On Sat, 20 Feb 1999, Zack Weinberg wrote:
>On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>>
>>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>>  > ELF. However, your patch won't hurt.
>>Yours works by introducing an ELF specific hack.
>>
>>Jason's patch, while not 100% correct either is a lot closer than yours since
>>it works for a large number of targets instead of just ELF.  The cases where
>>it fails should be minimial as far as I can tell.
>>
>>HJ, remember, we care about more than just Linux and ELF.  We have to.
>
>I don't really see using local symbols for constructors as an
>ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>ought to be able to use the same tactic on any system with named
>sections - at least XCOFF, and I know there are others.
>

I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
problems but anyway it is not carefully tested yet.

Andris

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

[H.J. Lu]

> >
> >I don't really see using local symbols for constructors as an
> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
> >ought to be able to use the same tactic on any system with named
> >sections - at least XCOFF, and I know there are others.
> >
> 
> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
> problems but anyway it is not carefully tested yet.
> 

Assume your test is right, you will see the problem if there is one.

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

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

[Andris Pavenis]

On Mon, 22 Feb 1999, H.J. Lu wrote:
>> >
>> >I don't really see using local symbols for constructors as an
>> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>> >ought to be able to use the same tactic on any system with named
>> >sections - at least XCOFF, and I know there are others.
>> >
>> 
>> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
>> problems but anyway it is not carefully tested yet.
>> 
>
>Assume your test is right, you will see the problem if there is one.
>

At that time I built 1.1.2pre1 with this patch and did only some very
preliminary tests. Now I tried it for my own applications and with some tests
I had and seems that all is Ok for DJGPP (Note that rather serious 
patches are required to build these version for DJGPP)

Andris

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

[Andris Pavenis]

On Mon, 22 Feb 1999, H.J. Lu wrote:
>> >
>> >I don't really see using local symbols for constructors as an
>> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>> >ought to be able to use the same tactic on any system with named
>> >sections - at least XCOFF, and I know there are others.
>> >
>> 
>> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
>> problems but anyway it is not carefully tested yet.
>> 
>
>Assume your test is right, you will see the problem if there is one.
>

At that time I built 1.1.2pre1 with this patch and did only some very
preliminary tests. Now I tried it for my own applications and with some tests
I had and seems that all is Ok for DJGPP (Note that rather serious 
patches are required to build these version for DJGPP)

Andris

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

[H.J. Lu]

> >
> >I don't really see using local symbols for constructors as an
> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
> >ought to be able to use the same tactic on any system with named
> >sections - at least XCOFF, and I know there are others.
> >
> 
> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
> problems but anyway it is not carefully tested yet.
> 

Assume your test is right, you will see the problem if there is one.

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

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

[Andris Pavenis]

On Sat, 20 Feb 1999, Zack Weinberg wrote:
>On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>>
>>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>>  > ELF. However, your patch won't hurt.
>>Yours works by introducing an ELF specific hack.
>>
>>Jason's patch, while not 100% correct either is a lot closer than yours since
>>it works for a large number of targets instead of just ELF.  The cases where
>>it fails should be minimial as far as I can tell.
>>
>>HJ, remember, we care about more than just Linux and ELF.  We have to.
>
>I don't really see using local symbols for constructors as an
>ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>ought to be able to use the same tactic on any system with named
>sections - at least XCOFF, and I know there are others.
>

I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
problems but anyway it is not carefully tested yet.

Andris

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

[Zack Weinberg]

On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>
>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>  > ELF. However, your patch won't hurt.
>Yours works by introducing an ELF specific hack.
>
>Jason's patch, while not 100% correct either is a lot closer than yours since
>it works for a large number of targets instead of just ELF.  The cases where
>it fails should be minimial as far as I can tell.
>
>HJ, remember, we care about more than just Linux and ELF.  We have to.

I don't really see using local symbols for constructors as an
ELF-specific hack.  HJ's implementation may be ELF-specific, but we
ought to be able to use the same tactic on any system with named
sections - at least XCOFF, and I know there are others.

zw

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

[Jeffrey A Law]

  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > ELF. However, your patch won't hurt.
Yours works by introducing an ELF specific hack.

Jason's patch, while not 100% correct either is a lot closer than yours since
it works for a large number of targets instead of just ELF.  The cases where
it fails should be minimial as far as I can tell.

HJ, remember, we care about more than just Linux and ELF.  We have to.



jeff

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

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:
> 
>  >> No matter what you use, please make sure ctors/dtors are local on
>  >> ELF.
> 
>  > Why is this necessary if we use Jason's patch?
> 
> It isn't, but it doesn't hurt, either.  I don't see any need for it in
> 1.1.2, though.
> 

You got it backward. Making ctors/dtors local on ELF FIXES the bug on
ELF. However, your patch won't hurt.

BTW, as far as file scope ctors/dtors on ELF are concerned, your patch
is not as good as making them local. This change will be in egcs
1.1.2/Linux.

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

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:

 >> No matter what you use, please make sure ctors/dtors are local on
 >> ELF.

 > Why is this necessary if we use Jason's patch?

It isn't, but it doesn't hurt, either.  I don't see any need for it in
1.1.2, though.

Jason

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

[Martin v. Loewis]

[making initializer functions static]
> Why is this necessary if we use Jason's patch?

Because of the example that triggered the whole thread: You use two
shared libraries which both have the same global function. Ian Taylor
tells me that this is legal and standard use, despite its violating
the odr. People do such things with shared libraries.

Now, you create global objects in each shared library, which are keyed
to the global function. The dynamic linker will then initialize one
object twice, and the other not-at-all.

If we think this is legal use, we should fix the problem.

Regards,
Martin

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

[Jeffrey A Law]

  In message < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de >you write:
  > [making initializer functions static]
  > > Why is this necessary if we use Jason's patch?
  > 
  > Because of the example that triggered the whole thread: You use two
  > shared libraries which both have the same global function. Ian Taylor
  > tells me that this is legal and standard use, despite its violating
  > the odr. People do such things with shared libraries.
  > 
  > Now, you create global objects in each shared library, which are keyed
  > to the global function. The dynamic linker will then initialize one
  > object twice, and the other not-at-all.
  > 
  > If we think this is legal use, we should fix the problem.
But doesn't Jason's patch avoid this problem by munging the name?


jeff

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

[Martin v. Loewis]

> But doesn't Jason's patch avoid this problem by munging the name?

Maybe I haven't seen Jason's patch, then. Current g++ only munges the
name of the source file, if that is used to provide uniqueness. If we
have a global symbol, we are dead sure that it is already unique, and
requires no munging.

Regards,
Martin

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

[Martin v. Loewis]

> But doesn't Jason's patch avoid this problem by munging the name?

Maybe I haven't seen Jason's patch, then. Current g++ only munges the
name of the source file, if that is used to provide uniqueness. If we
have a global symbol, we are dead sure that it is already unique, and
requires no munging.

Regards,
Martin

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

[Jeffrey A Law]

  In message < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de >you write:
  > [making initializer functions static]
  > > Why is this necessary if we use Jason's patch?
  > 
  > Because of the example that triggered the whole thread: You use two
  > shared libraries which both have the same global function. Ian Taylor
  > tells me that this is legal and standard use, despite its violating
  > the odr. People do such things with shared libraries.
  > 
  > Now, you create global objects in each shared library, which are keyed
  > to the global function. The dynamic linker will then initialize one
  > object twice, and the other not-at-all.
  > 
  > If we think this is legal use, we should fix the problem.
But doesn't Jason's patch avoid this problem by munging the name?


jeff

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

[Martin v. Loewis]

[making initializer functions static]
> Why is this necessary if we use Jason's patch?

Because of the example that triggered the whole thread: You use two
shared libraries which both have the same global function. Ian Taylor
tells me that this is legal and standard use, despite its violating
the odr. People do such things with shared libraries.

Now, you create global objects in each shared library, which are keyed
to the global function. The dynamic linker will then initialize one
object twice, and the other not-at-all.

If we think this is legal use, we should fix the problem.

Regards,
Martin

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

[Jeffrey A Law]

  In message < m10D8I7-00038sC@ocean.lucon.org >you write:
  > > 
  > > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
  > > 
  > >  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
  > >  > perfect, but it is good enough IMHO.
  > > 
  > >  > So, what changes do I need to pull into egcs-1.1.2?
  > > 
  > > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > > 
  > >         * tree.c (append_random_chars): New fn.
  > >         (get_file_function_name_long): Use it.
  > > 
  > > It will need to be massaged a bit because 1.1.x doesn't have the change f
  > or
  > > get_file_function_name_long, but that's not important.
  > > 
  > > Jason
  > 
  > No matter what you use, please make sure ctors/dtors are local on
  > ELF.
Why is this necessary if we use Jason's patch?

jeff

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

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
>  > perfect, but it is good enough IMHO.
> 
>  > So, what changes do I need to pull into egcs-1.1.2?
> 
> Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * tree.c (append_random_chars): New fn.
>         (get_file_function_name_long): Use it.
> 
> It will need to be massaged a bit because 1.1.x doesn't have the change for
> get_file_function_name_long, but that's not important.
> 
> Jason

No matter what you use, please make sure ctors/dtors are local on
ELF.

Thanks.


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

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

[Jeffrey A Law]

  In message < u9iud1iiwm.fsf@yorick.cygnus.com >you write:
  > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > 
  >         * tree.c (append_random_chars): New fn.
  >         (get_file_function_name_long): Use it.
  > 
  > It will need to be massaged a bit because 1.1.x doesn't have the change for
  > get_file_function_name_long, but that's not important.
Right.  I went back and extracted the get_file_function_name_long change and
installed it along with the change referenced above.

I also fixed up aoutos.h and installed the cp/decl2.c patch as has been
discussed.

This should fix the multiple definition problems.

jeff

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

[Jeffrey A Law]

  In message < u9iud1iiwm.fsf@yorick.cygnus.com >you write:
  > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > 
  >         * tree.c (append_random_chars): New fn.
  >         (get_file_function_name_long): Use it.
  > 
  > It will need to be massaged a bit because 1.1.x doesn't have the change for
  > get_file_function_name_long, but that's not important.
Right.  I went back and extracted the get_file_function_name_long change and
installed it along with the change referenced above.

I also fixed up aoutos.h and installed the cp/decl2.c patch as has been
discussed.

This should fix the multiple definition problems.

jeff

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
 > perfect, but it is good enough IMHO.

 > So, what changes do I need to pull into egcs-1.1.2?

Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>

        * tree.c (append_random_chars): New fn.
        (get_file_function_name_long): Use it.

It will need to be massaged a bit because 1.1.x doesn't have the change for
get_file_function_name_long, but that's not important.

Jason

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

[Jeffrey A Law]

  In message < u9ww1ii3mw.fsf@yorick.cygnus.com >you write:
  > The current code uses timestamp ^ pid directly, without going through the
  > random number generator.  The code was lifted from mkstemp in libiberty.
  > 
  > Really, this seems entirely adequate to me.  The number of translation
  > units that actually rely on this is small; witness how long it took to fix
  > this problem in the first place.
timestamp ^ pid seems quite reasonable to me too.  It's not 100% perfect, but
it is good enough IMHO.

So, what changes do I need to pull into egcs-1.1.2?

jeff

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

[Jason Merrill]

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

>>>>> "H" == H J Lu <hjl@lucon.org> writes:
 H> I see. How about removing hostname and domainname?

 H> For anonymouse namspace, they are global. I don't think random
 H> bits alone are any better than timestamp. How about timestamp +
 H> random bits?

 > Sure, that's fine.  But, why bother?  Random bits are very, very good.
 > Anything is else is an unnecessary complication.  Using more random
 > bits is easier that throwing in any other attempted uniquifications.

 > We just need a pile of bits.  If I were you, I'd seed the random
 > number generator with a hash of timestamp + pid + ip address, and call
 > it good enough.

The current code uses timestamp ^ pid directly, without going through the
random number generator.  The code was lifted from mkstemp in libiberty.

Really, this seems entirely adequate to me.  The number of translation
units that actually rely on this is small; witness how long it took to fix
this problem in the first place.

Jason

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

[H.J. Lu]

> 
> >>>>> "H" == H J Lu <hjl@lucon.org> writes:
> 
>     H> Here is my proposal. main () in toplev.c calls unique_string ()
>     H> to initialize a static variable in tree.c:
> 
> In my opinion, this is not a good proposal.  In another life, I work
> on issues of computer security, and silently putting things that might
> reveal the hostname where the program is compiled in .o files is not
> at all a good thing.

I see. How about removing hostname and domainname?

> 
> If we can make the functions static, the problem goes away, right?  If
> not, then sufficiently many random bits is just fine.  I would guess
> that 2048 would be more than enough for quite some time to come.
> 

For anonymouse namspace, they are global. I don't think random bits
alone are any better than timestamp. How about timestamp + random bits?


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

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

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> Here is my proposal. main () in toplev.c calls unique_string ()
    H> to initialize a static variable in tree.c:

In my opinion, this is not a good proposal.  In another life, I work
on issues of computer security, and silently putting things that might
reveal the hostname where the program is compiled in .o files is not
at all a good thing.

If we can make the functions static, the problem goes away, right?  If
not, then sufficiently many random bits is just fine.  I would guess
that 2048 would be more than enough for quite some time to come.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

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

[H.J. Lu]

> 
> 
> 
>   In message < m10Boh4-000392C@ocean.lucon.org >you write:
>   > It is a very hard problem. It may not have solutons for all platforms.
>   > But it doesn't mean we should not fix those we can fix.
> But it also doesn't mean we take the stance of fixing linux and ignoring
> everything else.
> 

Here is my proposal. main () in toplev.c calls unique_string () to
initialize a static variable in tree.c:

static char *file_function_name_base;

with

	file_function_name_base = unique_string ();

We also add a counter in tree.c:

static int file_function_name_counter;

get_file_function_name in tree.c will create a file funtcion name with

	file_function_name = file_function_name_base
			     + main_input_filename
			     + file_function_name_counter;

This way we can say with quite confidence that file_function_name will
be unique across all machines in the world for a given OS on a given
arch if they are configured properly. Of course, it may not work for
all OSes. But it should cover most if not all Unix-alike systems.

> Furthermore, this is an ABI/API change, we want to be very careful making
> such changes.
> 

I am not sure if the ABI/API change caused by making global ctors/dtors
static is visible to user. At least, it should be safe on ELF systems.


-- 
H.J. Lu (hjl@gnu.org)
---
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#if defined HAVE_SYS_UTSNAME_H && defined HAVE_UNAME
#include <sys/utsname.h>
#endif

#if defined HAVE_TIME_H && defined HAVE_STRFTIME \
    && defined HAVE_GMTIME && defined HAVE_TIME
#include <time.h>
#endif

#define xmalloc	malloc

#define is_valid_symbol_char(c) \
  ((c) == '_' || (c) == '.' || ((c) >= '0' && (c) <= '9') \
   || ((c) >= 'a' && (c) <= 'z') || ((c) >= 'A' && (c) <= 'Z'))

char *
unique_string ()
{
  char *domainname = NULL;
  char *hostname = NULL;
  char *sysname = NULL;
  char *release = NULL;
  char *version = NULL;
  char *machine = NULL;
  char current_time [] = "yyyymmddhhmmss";
  long pid = getpid ();
  char *unique_name;
  int len;

#ifdef HAVE_GETDOMAINNAME
  {
    len = 0;
    do
      {
	len += 128;
	domainname = (char *) alloca (len);
	if (getdomainname (domainname, len) == 0)
	  break;
	else
	  domainname = NULL;
      }
    while (len < 512);
  }
#endif

#ifdef HAVE_GETHOSTNAME
  {
    len = 0;
    do
      {
	len += 128;
	hostname = (char *) alloca (len);
	if (gethostname (hostname, len) == 0)
	  break;
	else
	  hostname = NULL;
      }
    while (len < 512);
  }
#endif

#if defined HAVE_UNAME && defined HAVE_SYS_UTSNAME_H
  {
    struct utsname utsname;

    if (uname (&utsname) == 0)
      {
#ifdef HAVE_DOMAINNAME_IN_UTSNAME
        if (!domainname)
	  domainname = utsname.domainname;
#endif
#ifdef HAVE_NODENAME_IN_UTSNAME
        if (!hostname)
	  hostname = utsname.nodename;
#endif
#ifdef HAVE_SYSNAME_IN_UTSNAME
	sysname = utsname.sysname;
#endif
#ifdef HAVE_RELEASE_IN_UTSNAME
	release = utsname.release;
#endif
#ifdef HAVE_VERSION_IN_UTSNAME
	version = utsname.version;
#endif
#ifdef HAVE_MACHINE_IN_UTSNAME
	machine = utsname.machine;
#endif
      }
  }
#endif

  if (!domainname || *domainname == '\0')
    domainname = "localdomain";

  if (!hostname || *hostname == '\0')
    hostname = "localhost";

  if (!sysname || *sysname == '\0')
    sysname = "UnknownOS";

  if (!release || *release == '\0')
    release = "UnknownRelease";

  if (!version || *version == '\0')
    version = "UnknownVersion";

  if (!machine || *machine == '\0')
    machine = "UnknownMachine";

#if defined HAVE_STRFTIME && defined HAVE_GMTIME && defined HAVE_TIME
  {
    time_t t;
    
    t = time (NULL);
    if (strftime (current_time, sizeof (current_time),
    		  "%Y%m%d%H%M%S", gmtime (&t)) == 0)
      strcpy (current_time, "yyyymmddhhmmss");
  }
#endif

  {
    char *dot = strchr (hostname, '.');

    if (!dot || strchr (++dot, '.') == NULL)
      {
        /* There are no 2 dots in hostname. We need to append the
	   domainname. */
	len = 1 + strlen (hostname) + 1 + strlen (domainname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s.%s%s%s%s%s%s%.8x",
		 hostname, domainname, sysname, release, version,
		 machine, current_time, pid);
      }
    else
      {
	len = 1 + strlen (hostname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s%s%s%s%s%s%.8x",
		 hostname, sysname, release, version,
		 machine, current_time, pid);
      }
  }

  {
    int i;

    for (i = 1; i < len - 1 - sizeof (current_time) - 8; i++)
      {
        if (!is_valid_symbol_char (unique_name [i]))
	  unique_name [i] = '_';
      }
  }
  return unique_name;
}

main ()
{
  printf ("%s\n", unique_string ());
}

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

[Jeffrey A Law]

  In message < m10Boh4-000392C@ocean.lucon.org >you write:
  > It is a very hard problem. It may not have solutons for all platforms.
  > But it doesn't mean we should not fix those we can fix.
But it also doesn't mean we take the stance of fixing linux and ignoring
everything else.

Furthermore, this is an ABI/API change, we want to be very careful making
such changes.

jeff

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

[H.J. Lu]

> 
> 
>   In message < m10BoHn-000392C@ocean.lucon.org >you write:
>   > > 
>   > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
>   > ing
>   > > > concrete yet.
>   > > 
>   > > I think the minimal solution is to make initializer symbols static on
>   > > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > > whether it does what it promises to do.
>   > 
>   > I am only interested in Linux. If we really cannot fix the problem for
>   > all platforms, it is ok with me as long as Linux is ok :-(.
> That may be your only concern, but this project is not just a linux compiler.
> We have to think about broader scopes than just linux.
> 

It is a very hard problem. It may not have solutons for all platforms.
But it doesn't mean we should not fix those we can fix.


H.J.

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

[Jeffrey A Law]

  In message < m10BoHn-000392C@ocean.lucon.org >you write:
  > > 
  > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
  > ing
  > > > concrete yet.
  > > 
  > > I think the minimal solution is to make initializer symbols static on
  > > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > > whether it does what it promises to do.
  > 
  > I am only interested in Linux. If we really cannot fix the problem for
  > all platforms, it is ok with me as long as Linux is ok :-(.
That may be your only concern, but this project is not just a linux compiler.
We have to think about broader scopes than just linux.



jeff

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

[H.J. Lu]

> 
> > So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> > concrete yet.
> 
> I think the minimal solution is to make initializer symbols static on
> ELF systems. HJ has a patch, although I haven't reviewed it to see
> whether it does what it promises to do.

I am only interested in Linux. If we really cannot fix the problem for
all platforms, it is ok with me as long as Linux is ok :-(.

> 
> If somebody can propose a patch that produces significantly
> more-unique symbols than the current code, this should also go into 1.2.
> In this respect, HJ's other patch does not qualify, IMHO.
> 

To me, "significantly more-unique" is still bet on luck. I really
don't like it. I will do something for Linux one way or the other
if I don't like what I see.


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

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

[Jeffrey A Law]

  In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
  > I think the minimal solution is to make initializer symbols static on
  > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > whether it does what it promises to do.
I'm not even sure that is correct.

At one time it was possible to build a .o and suck it into your address
space via dynamic loader calls.  And if the .o has static ctors/dtors, the
application is responsible for firing them -- and to do so it must be able
to query the dynamic loader for predictable symbol names.

It's basically the same problem we have with shared libraries for non-ELF
targets.

jeff

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

[Martin v. Loewis]

> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.

For ELF targets, do you really think this is a widely-used approach?
I'd rather think you'd typically use -ldl and dlopen, which means that
you have to produce a shared library first. If you do that, libdl will
call the constructors even though it doesn't have a symbol name.

If you insist on loading relocatable ELF objects dynamically, you
still can do that: just locate and execute the .init section. No
symbol name needed.

Regards,
Martin

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

[Jeffrey A Law]

  In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
  > For ELF targets, do you really think this is a widely-used approach?
Widely used is not the criteria.  Lots of things are not widely used, but
we still have to support them.

  > If you insist on loading relocatable ELF objects dynamically, you
  > still can do that: just locate and execute the .init section. No
  > symbol name needed.
Do we have a .init section for just the .o?  If so, then ignore this issue.

jeff

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

[Martin v. Loewis]

> Do we have a .init section for just the .o?  If so, then ignore this issue.

No, but we have .ctors. All .ctors sections get concatenated, and
build an array of initializer functions.

Regards,
Martin

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

[Martin v. Loewis]

> Do we have a .init section for just the .o?  If so, then ignore this issue.

No, but we have .ctors. All .ctors sections get concatenated, and
build an array of initializer functions.

Regards,
Martin

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

[Jeffrey A Law]

  In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
  > For ELF targets, do you really think this is a widely-used approach?
Widely used is not the criteria.  Lots of things are not widely used, but
we still have to support them.

  > If you insist on loading relocatable ELF objects dynamically, you
  > still can do that: just locate and execute the .init section. No
  > symbol name needed.
Do we have a .init section for just the .o?  If so, then ignore this issue.

jeff

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

[Steinar Bang]

>>>>> "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>:

> For ELF targets, do you really think this is a widely-used approach?
> I'd rather think you'd typically use -ldl and dlopen, which means
> that you have to produce a shared library first. If you do that,
> libdl will call the constructors even though it doesn't have a
> symbol name.

That's what I did and that's where my application croaked.  I
implemented singleton subclasses of an abstract class, and put a
static instance of each class in the compilation unit it was defined
in.

When the .so is loaded the constructor of the singleton is run, and it 
registers itself.

My application croaked on the static instances.  It didn't want more
than one of those in each executable or .so.

For a minimal test case, please see:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

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

[Steinar Bang]

>>>>> "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>:

> For ELF targets, do you really think this is a widely-used approach?
> I'd rather think you'd typically use -ldl and dlopen, which means
> that you have to produce a shared library first. If you do that,
> libdl will call the constructors even though it doesn't have a
> symbol name.

That's what I did and that's where my application croaked.  I
implemented singleton subclasses of an abstract class, and put a
static instance of each class in the compilation unit it was defined
in.

When the .so is loaded the constructor of the singleton is run, and it 
registers itself.

My application croaked on the static instances.  It didn't want more
than one of those in each executable or .so.

For a minimal test case, please see:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
 >> For ELF targets, do you really think this is a widely-used approach?

 > Widely used is not the criteria.  Lots of things are not widely used, but
 > we still have to support them.

We have never supported running ctors for a single .o, and I don't see any
reason to start.  I've never heard of loading a single .o dynamically
without linking it into a shared object.

 >> If you insist on loading relocatable ELF objects dynamically, you
 >> still can do that: just locate and execute the .init section. No
 >> symbol name needed.

 > Do we have a .init section for just the .o?  If so, then ignore this issue.

We have an .init section; we don't have the _init function if we don't link
against crt[in].o.

Jason

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

[Joe Buck]

> We have never supported running ctors for a single .o, and I don't see any
> reason to start.  I've never heard of loading a single .o dynamically
> without linking it into a shared object.

Really?  You don't remember ld -A on old BSD (or, to reveal my age, Unix
version 7) systems?  It predates the existence of shared libraries on
Unix.  That's how I implemented incremental linking in Ptolemy on SunOS 4.
It required running a ctor for a single .o.

(Yes, -ldl is more flexible).

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

[Joe Buck]

> We have never supported running ctors for a single .o, and I don't see any
> reason to start.  I've never heard of loading a single .o dynamically
> without linking it into a shared object.

Really?  You don't remember ld -A on old BSD (or, to reveal my age, Unix
version 7) systems?  It predates the existence of shared libraries on
Unix.  That's how I implemented incremental linking in Ptolemy on SunOS 4.
It required running a ctor for a single .o.

(Yes, -ldl is more flexible).

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

[Jeffrey A Law]

  In message < u9yalyi3t6.fsf@yorick.cygnus.com >you write:
  > We have never supported running ctors for a single .o, and I don't see any
  > reason to start.  I've never heard of loading a single .o dynamically
  > without linking it into a shared object.
I was doing this in the early 90s.  Two schemes, one involved sucking
in the .o via a dynamic linker call, which put the ctor/dtor issue in the
hands of the code which made the dl_open calls.  The second scheme was a poor
man's shared library scheme using ld -A.  I don't remember what we did for
ctors/dtors with the ld -A scheme.



  >  > Do we have a .init section for just the .o?  If so, then ignore this
  >  > issue.
  > 
  > We have an .init section; we don't have the _init function if we don't link
  > against crt[in].o.
OK.  Let's consider this a non-issue for ELF.

jeff

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

[Jeffrey A Law]

  In message < u9yalyi3t6.fsf@yorick.cygnus.com >you write:
  > We have never supported running ctors for a single .o, and I don't see any
  > reason to start.  I've never heard of loading a single .o dynamically
  > without linking it into a shared object.
I was doing this in the early 90s.  Two schemes, one involved sucking
in the .o via a dynamic linker call, which put the ctor/dtor issue in the
hands of the code which made the dl_open calls.  The second scheme was a poor
man's shared library scheme using ld -A.  I don't remember what we did for
ctors/dtors with the ld -A scheme.



  >  > Do we have a .init section for just the .o?  If so, then ignore this
  >  > issue.
  > 
  > We have an .init section; we don't have the _init function if we don't link
  > against crt[in].o.
OK.  Let's consider this a non-issue for ELF.

jeff

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

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
 >> For ELF targets, do you really think this is a widely-used approach?

 > Widely used is not the criteria.  Lots of things are not widely used, but
 > we still have to support them.

We have never supported running ctors for a single .o, and I don't see any
reason to start.  I've never heard of loading a single .o dynamically
without linking it into a shared object.

 >> If you insist on loading relocatable ELF objects dynamically, you
 >> still can do that: just locate and execute the .init section. No
 >> symbol name needed.

 > Do we have a .init section for just the .o?  If so, then ignore this issue.

We have an .init section; we don't have the _init function if we don't link
against crt[in].o.

Jason

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

[Martin v. Loewis]

> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.

For ELF targets, do you really think this is a widely-used approach?
I'd rather think you'd typically use -ldl and dlopen, which means that
you have to produce a shared library first. If you do that, libdl will
call the constructors even though it doesn't have a symbol name.

If you insist on loading relocatable ELF objects dynamically, you
still can do that: just locate and execute the .init section. No
symbol name needed.

Regards,
Martin

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

[H.J. Lu]

> 
> 
> 
>   In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
>   > I think the minimal solution is to make initializer symbols static on
>   > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > whether it does what it promises to do.
> I'm not even sure that is correct.
> 
> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.
> 

Now you are talking non-standard stuff here. I can say it is up to
the application to figure out those .ctor/.dtor sections and call
those .ctor/.dtor sections at the appropriate time. All the information
is there. The ELF linker uses it. So can the application.

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

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

[H.J. Lu]

> 
> 
> 
>   In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
>   > I think the minimal solution is to make initializer symbols static on
>   > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > whether it does what it promises to do.
> I'm not even sure that is correct.
> 
> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.
> 

Now you are talking non-standard stuff here. I can say it is up to
the application to figure out those .ctor/.dtor sections and call
those .ctor/.dtor sections at the appropriate time. All the information
is there. The ELF linker uses it. So can the application.

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

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

[Jeffrey A Law]

  In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
  > I think the minimal solution is to make initializer symbols static on
  > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > whether it does what it promises to do.
I'm not even sure that is correct.

At one time it was possible to build a .o and suck it into your address
space via dynamic loader calls.  And if the .o has static ctors/dtors, the
application is responsible for firing them -- and to do so it must be able
to query the dynamic loader for predictable symbol names.

It's basically the same problem we have with shared libraries for non-ELF
targets.

jeff

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

[Martin v. Loewis]

> So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> concrete yet.

I think the minimal solution is to make initializer symbols static on
ELF systems. HJ has a patch, although I haven't reviewed it to see
whether it does what it promises to do.

If somebody can propose a patch that produces significantly
more-unique symbols than the current code, this should also go into 1.2.
In this respect, HJ's other patch does not qualify, IMHO.

Regards,
Martin

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

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > I think the minimal solution is to make initializer symbols static on
 > ELF systems.

This seems reasonable.

 > If somebody can propose a patch that produces significantly
 > more-unique symbols than the current code, this should also go into 1.2.

I think the current development code produces adequately unique symbols,
through randomness.  Cases where such disambiguation are rare in any case;
they only occur when the translation units don't contain any symbols known
to be unique, which should not occur often in real code.

Jason

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

[H.J. Lu]

>  > If somebody can propose a patch that produces significantly
>  > more-unique symbols than the current code, this should also go into 1.2.
> 
> I think the current development code produces adequately unique symbols,
> through randomness.  Cases where such disambiguation are rare in any case;
> they only occur when the translation units don't contain any symbols known
> to be unique, which should not occur often in real code.
> 

I looked at the code. It is better than 1.1.1. But it still can be
improved. If noone does anything to it, I will include my unique_string
patch in egcs 1.1.2/Linux.

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

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

[H.J. Lu]

>  > If somebody can propose a patch that produces significantly
>  > more-unique symbols than the current code, this should also go into 1.2.
> 
> I think the current development code produces adequately unique symbols,
> through randomness.  Cases where such disambiguation are rare in any case;
> they only occur when the translation units don't contain any symbols known
> to be unique, which should not occur often in real code.
> 

I looked at the code. It is better than 1.1.1. But it still can be
improved. If noone does anything to it, I will include my unique_string
patch in egcs 1.1.2/Linux.

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

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

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > I think the minimal solution is to make initializer symbols static on
 > ELF systems.

This seems reasonable.

 > If somebody can propose a patch that produces significantly
 > more-unique symbols than the current code, this should also go into 1.2.

I think the current development code produces adequately unique symbols,
through randomness.  Cases where such disambiguation are rare in any case;
they only occur when the translation units don't contain any symbols known
to be unique, which should not occur often in real code.

Jason

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

[Jeffrey A Law]

  In message < m108PtF-00038sC@ocean.lucon.org >you write:
  > My proposal does have some limitations. I hope someone can come
  > up with a better solution. This serious bug must be fixed in
  > egcs 1.1.2. The sooner, the better.
So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
concrete yet.


jeff

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

[H.J. Lu]

> 
> > How about we use
> > 
> > 	machinename+pid+filename+strftime+staticcounter+randomstuff
> > 
> > The possiblility for clash should be very low. I'd like to see it
> > be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.
> 
> I just had a complaint of somebody running into the same problem,
> different scenario:
> 
> He had a number of shared libraries, all starting with the same global
> function. Of course, this is ill-formed (duplicate definitions), but
> the linker didn't complain, so he thought it's all-right. But it
> wasn't: g++ keyed initializers to this function, and the same
> initializer got invoked twice; another initializer wasn't called.
> 
> So I now think that the initializer symbols should be static if we are
> not collect2ing them. 

That is what I have been saying all along.

> 
> Still, coming up with a better 'unique hash' is worthwhile. It should
> be well-designed though: We had several attempts to do it right, and
> still didn't. In your proposal, I see a number of problems:
> 
> a) pid, randomstuff might not be available on all systems. In
>    particular, systems that don't get initializers right probably
>    don't have a number of other things.
> 
> b) Don't produce too long strings. It might exceed assembler
>    restrictions.
> 

My proposal does have some limitations. I hope someone can come
up with a better solution. This serious bug must be fixed in
egcs 1.1.2. The sooner, the better.

Please remember we need a universal unique hash for every different
file on every single machine for the same platform. It is a tough
one. But we have to do it.

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

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

[Martin v. Loewis]

> How about we use
> 
> 	machinename+pid+filename+strftime+staticcounter+randomstuff
> 
> The possiblility for clash should be very low. I'd like to see it
> be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

I just had a complaint of somebody running into the same problem,
different scenario:

He had a number of shared libraries, all starting with the same global
function. Of course, this is ill-formed (duplicate definitions), but
the linker didn't complain, so he thought it's all-right. But it
wasn't: g++ keyed initializers to this function, and the same
initializer got invoked twice; another initializer wasn't called.

So I now think that the initializer symbols should be static if we are
not collect2ing them. 

Still, coming up with a better 'unique hash' is worthwhile. It should
be well-designed though: We had several attempts to do it right, and
still didn't. In your proposal, I see a number of problems:

a) pid, randomstuff might not be available on all systems. In
   particular, systems that don't get initializers right probably
   don't have a number of other things.

b) Don't produce too long strings. It might exceed assembler
   restrictions.

Regards,
Martin
 

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

[H.J. Lu]

> 
> > Do 'D' and 'I' have to be global?
> 
> I'm not sure. As you've found, they don't have to be for ELF. I don't
> know what the rationale was for making them global; it seems this
> knowledge is lost...
> 

collect2 is used for globcl ctors/dtors on some systems.

> > I am not sure if we should worry about anonymous namespaces. What
> > will happen when 2 anonymous namespaces have the same name?
> 
> Bad things. Anonymous namespaces allow you to put
> 
> namespace{
>   int dummy;
> }
> 
> into a header file, and you should get a different variable in each
> object file. More importantly, you can do
> 
> namespace{
>   class Handle{
>     Handle(){}
>   };
> }
> 
> in an implementation and expect that it won't clash with somebody
> else's Handle class. If the two anonymous namespaces have the same
> name, you'll get a clash.

How about we use

	machinename+pid+filename+strftime+staticcounter+randomstuff

The possiblility for clash should be very low. I'd like to see it
be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

Thanks.


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

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

[Jeffrey A Law]

  In message < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de >you write:
  > > Do 'D' and 'I' have to be global?
  > 
  > I'm not sure. As you've found, they don't have to be for ELF. I don't
  > know what the rationale was for making them global; it seems this
  > knowledge is lost...
I haven't followed this whole discussion, so maybe I'm completely off base
with the discussion (also allow that I don't use C++ enough to always know
what y'all are talking about :-), but a shared library initializer routine
must be global.

Consider a non-ELF system where the shared library is loaded explicitly at
run time by the main program.

The main program is responsible for calling the shared library's initializer 
routine to fire the global ctors/dtors.

To do that the program has to query the dynamic linker to see if the library
has a function with the (well known) initializer name which typically has the
form _GLOBAL__FI_<library_name>.  If the initializer function is static, then
we lose.

If you are talking about something different, then ignore me :-)

jeff

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

[Martin v. Loewis]

> I haven't followed this whole discussion, so maybe I'm completely off base
> with the discussion (also allow that I don't use C++ enough to always know
> what y'all are talking about :-), but a shared library initializer routine
> must be global.
> 
> Consider a non-ELF system where the shared library is loaded explicitly at
> run time by the main program.

Yes, non-ELF systems are a problem, and whatever the fix we find,
we'll also find a way to break it.

What HJ and I now agree on is that we should fix this problem on ELF
systems for good, regardless of the problems experienced on other
systems. So on ELF systems (and other systems with 'real' initializer
functionality), the global ctor function does not need to be external.

Regards,
Martin

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

[Martin v. Loewis]

> I haven't followed this whole discussion, so maybe I'm completely off base
> with the discussion (also allow that I don't use C++ enough to always know
> what y'all are talking about :-), but a shared library initializer routine
> must be global.
> 
> Consider a non-ELF system where the shared library is loaded explicitly at
> run time by the main program.

Yes, non-ELF systems are a problem, and whatever the fix we find,
we'll also find a way to break it.

What HJ and I now agree on is that we should fix this problem on ELF
systems for good, regardless of the problems experienced on other
systems. So on ELF systems (and other systems with 'real' initializer
functionality), the global ctor function does not need to be external.

Regards,
Martin

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

[Jeffrey A Law]

  In message < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de >you write:
  > > Do 'D' and 'I' have to be global?
  > 
  > I'm not sure. As you've found, they don't have to be for ELF. I don't
  > know what the rationale was for making them global; it seems this
  > knowledge is lost...
I haven't followed this whole discussion, so maybe I'm completely off base
with the discussion (also allow that I don't use C++ enough to always know
what y'all are talking about :-), but a shared library initializer routine
must be global.

Consider a non-ELF system where the shared library is loaded explicitly at
run time by the main program.

The main program is responsible for calling the shared library's initializer 
routine to fire the global ctors/dtors.

To do that the program has to query the dynamic linker to see if the library
has a function with the (well known) initializer name which typically has the
form _GLOBAL__FI_<library_name>.  If the initializer function is static, then
we lose.

If you are talking about something different, then ignore me :-)

jeff

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

[Martin v. Loewis]

> Do 'D' and 'I' have to be global?

I'm not sure. As you've found, they don't have to be for ELF. I don't
know what the rationale was for making them global; it seems this
knowledge is lost...

> I am not sure if we should worry about anonymous namespaces. What
> will happen when 2 anonymous namespaces have the same name?

Bad things. Anonymous namespaces allow you to put

namespace{
  int dummy;
}

into a header file, and you should get a different variable in each
object file. More importantly, you can do

namespace{
  class Handle{
    Handle(){}
  };
}

in an implementation and expect that it won't clash with somebody
else's Handle class. If the two anonymous namespaces have the same
name, you'll get a clash.

Regards,
Martin

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

[H.J. Lu]

> 
> > 1. Can we identify the cases where get_file_function_name_long () is
> > called to generate a name for a global function unique to the
> > resulting executable binary and all the shared libraries it uses?
> 
> There are currently three different 'type' arguments passed to that
> function, 'D', 'I', and 'N'. For 'D' and 'I', additional mangling
> might indicate the initializer priority. For 'N', the resulting name
> will be an anonymous namespace.

Do 'D' and 'I' have to be global?

> 
> > 2. Do they have to be global?
> 
> In the case of anonymous namespaces, absolutely, yes. I proposed to
> make anonymous namespaces (and everything inside) static at one time,
> but it was decided that this approach would defeat upcoming
> implementations of exported templates.
> 

I am not sure if we should worry about anonymous namespaces. What
will happen when 2 anonymous namespaces have the same name?


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

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

[James Mansion]

> H.J.Lu wrote:
> In case of the C++ ctor/dtor, collect2 is not needed for ELF, we can
> make it local. My patch does that. If they have to be global, we can
> add strftime () with hostname in addition to append_random_chars ().
> It should have better chances to be unique. But I really want to get
> rid of the global function all together.

Wouldn't it be as easy to use something closely based on the
algorithm for generating DCE GUIDs?

Even if we have substitute IP address for the MAC address, its still
likely to be pretty good, and is at least in some sense or other
'standard'.  If the platform has a GUID generator, it can be used
directly.

James


Demonstration NTMail - see http://www.ntmail.co.uk

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

[James Mansion]

> H.J.Lu wrote:
> In case of the C++ ctor/dtor, collect2 is not needed for ELF, we can
> make it local. My patch does that. If they have to be global, we can
> add strftime () with hostname in addition to append_random_chars ().
> It should have better chances to be unique. But I really want to get
> rid of the global function all together.

Wouldn't it be as easy to use something closely based on the
algorithm for generating DCE GUIDs?

Even if we have substitute IP address for the MAC address, its still
likely to be pretty good, and is at least in some sense or other
'standard'.  If the platform has a GUID generator, it can be used
directly.

James


Demonstration NTMail - see http://www.ntmail.co.uk

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

[Jeffrey A Law]

  In message < m106iAc-000390C@ocean.lucon.org >you write:
  > > 
  > > On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
  > > 
  > > > I have no idea if this patch is correct. But it works for me. gcc
  > > > seems to pick a poor choice of function name for global constructors
  > > > and destructors. It may not be unique across files.
  > > 
  > > AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
  > > matter of porting his fix to the branch.
  > > 
  > 
  > I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
  > is not 100% safe since it bets on luck. My second patch is 100% safe.
  > But it only covers ctors/dtors in C++ and only works on ELF.
In what way does it "bets on luck"?

Such statements carry far more weight when you take the time to explain them.

jeff

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

[H.J. Lu]

> 
> On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
> 
> > I have no idea if this patch is correct. But it works for me. gcc
> > seems to pick a poor choice of function name for global constructors
> > and destructors. It may not be unique across files.
> 
> AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
> matter of porting his fix to the branch.
> 

I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
is not 100% safe since it bets on luck. My second patch is 100% safe.
But it only covers ctors/dtors in C++ and only works on ELF.

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

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

[Alexandre Oliva]

On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:

> I have no idea if this patch is correct. But it works for me. gcc
> seems to pick a poor choice of function name for global constructors
> and destructors. It may not be unique across files.

AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
matter of porting his fix to the branch.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

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

[H.J. Lu]

> 
> Hi,
> 
> I have no idea if this patch is correct. But it works for me. gcc
> seems to pick a poor choice of function name for global constructors
> and destructors. It may not be unique across files.
> 
> Thanks.
> 
> H.J.
> ----
> Fri Jan 29 17:15:59 1999  H.J. Lu  (hjl@gnu.org)
> 
> 	* decl2.c (start_objects): Make global constructors and
> 	destructors unique.
> 
> 
> --- ../../../../import/egcs-1.1.1/egcs/gcc/cp/decl2.c	Mon Nov  9 01:32:04 1998
> +++ ./decl2.c	Fri Jan 29 17:18:18 1999
> @@ -2943,6 +2943,12 @@ start_objects (method_type)
>  					NULL_TREE),
>  		  NULL_TREE, 0);
>  
> +  /* It is a file scope function. */
> +  if (flag_weak)
> +    make_decl_one_only (current_function_decl);
> +  else
> +    TREE_PUBLIC (current_function_decl) = 0;
> +
>    store_parm_decls ();
>    pushlevel (0);
>    clear_last_expr ();
> 

The patch above is incorrect. The patch ennclosed here only works
when ASM_OUTPUT_CONSTRUCTOR and ASM_OUTPUT_DESTRUCTOR are defined.
It should cover all ELF systems, including Linux. For othe systems,
gcc has to come up with a way to generate a unique global function
name for every single call,  from all existing/future egcs binaries,
to get_file_function_name (). I saw the egcs in CVS try to do that.
I'd like to see it in egcs 1.1.2. My patch here makes the C++ file
scope constructors/destructors safe on ELF systems. It should work
in egcs 1.1.1 also.

Thanks.

H.J.
----
Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)

	* decl2.c (start_objects): Make file scope constructors and
	destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
	ASM_OUTPUT_DESTRUCTOR are defined.

--- ../../../../import/egcs/gcc/cp/decl2.c	Tue Nov 10 07:44:01 1998
+++ ./decl2.c	Fri Jan 29 19:58:34 1999
@@ -2943,6 +2943,11 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
+  /* It can be a static function with .ctors/.dtors sections. */
+  TREE_PUBLIC (current_function_decl) = 0;
+#endif
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();

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

[Mike Stump]

> Date: Sun, 21 Feb 1999 12:04:24 +0100 (EET)
> From: Kamil Iskra <kamil@dwd.interkom.pl>
> To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> I don't get it. What's so difficult about introducing a new target
> macro that conveys precisely this information?

Nothing.  Writing bad code that is poorly design and unmaintainable is
easy.  Nothing hard about it.  Unfortunately, we try and write
maintainable and well designed code.  This is where `hardness' comes
into play.

Any feature that works on one system that obscures bugs on other
systems leads to fragile software.  It is usually good to avoid
fragile software, if possible.  When it works that same exact way on
all platforms, then we win bigger.  Winning is good.

It is a delicate balance between this type of goodness and superior
codegen strategies.  (static being superior)

I haven't voiced too much of an opinion in this thread, because I am
unsure which is better.  I like that Linux catches random bugs that
others might see on other platforms.  I like fixes that once fixed,
fixes all problems on all platforms.  Adding this special new macro,
means that we can no longer have symmetry across targets.  Testing
Linux, means testing even less of the compiler.

For example, adding a cryptgraphic checksum based upon the source code
of the translation unit is better, because then it works more often on
Liinux and it works more often on all platforms.  The more that I
think of random bits (pid, time, hostname) injected into the output of
the compiler, the more I don't like it, as then binary object
comparisons don't work and some people like comparing the output of
the compiler to verify that it is working properly.  Ask how many
people like timestamps, I think most of us hate them.  If you want a
timestamp, stat it.

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

[Mike Stump]

> Date: Sun, 21 Feb 1999 12:04:24 +0100 (EET)
> From: Kamil Iskra <kamil@dwd.interkom.pl>
> To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> I don't get it. What's so difficult about introducing a new target
> macro that conveys precisely this information?

Nothing.  Writing bad code that is poorly design and unmaintainable is
easy.  Nothing hard about it.  Unfortunately, we try and write
maintainable and well designed code.  This is where `hardness' comes
into play.

Any feature that works on one system that obscures bugs on other
systems leads to fragile software.  It is usually good to avoid
fragile software, if possible.  When it works that same exact way on
all platforms, then we win bigger.  Winning is good.

It is a delicate balance between this type of goodness and superior
codegen strategies.  (static being superior)

I haven't voiced too much of an opinion in this thread, because I am
unsure which is better.  I like that Linux catches random bugs that
others might see on other platforms.  I like fixes that once fixed,
fixes all problems on all platforms.  Adding this special new macro,
means that we can no longer have symmetry across targets.  Testing
Linux, means testing even less of the compiler.

For example, adding a cryptgraphic checksum based upon the source code
of the translation unit is better, because then it works more often on
Liinux and it works more often on all platforms.  The more that I
think of random bits (pid, time, hostname) injected into the output of
the compiler, the more I don't like it, as then binary object
comparisons don't work and some people like comparing the output of
the compiler to verify that it is working properly.  Ask how many
people like timestamps, I think most of us hate them.  If you want a
timestamp, stat it.