* multiple definitions of 'xxx keyed to...' in egcs-1.1.1 @ 1999-01-21 0:36 Steinar Bang 1999-01-21 2:44 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 0 siblings, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-21 0:36 UTC (permalink / raw) To: egcs 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-21 0:36 multiple definitions of 'xxx keyed to...' in egcs-1.1.1 Steinar Bang @ 1999-01-21 2:44 ` Steinar Bang 1999-01-21 23:48 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-21 2:44 UTC (permalink / raw) To: egcs >>>>> 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). ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-21 2:44 ` Steinar Bang @ 1999-01-21 23:48 ` Steinar Bang 1999-01-22 0:37 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-21 23:48 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-21 23:48 ` Steinar Bang @ 1999-01-22 0:37 ` H.J. Lu 1999-01-22 0:42 ` Steinar Bang ` (2 more replies) 1999-01-31 23:58 ` Steinar Bang 1 sibling, 3 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-22 0:37 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:37 ` H.J. Lu @ 1999-01-22 0:42 ` Steinar Bang 1999-01-22 0:48 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1999-01-22 7:05 ` Andris Pavenis 1999-01-31 23:58 ` H.J. Lu 2 siblings, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-22 0:42 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:42 ` Steinar Bang @ 1999-01-22 0:48 ` H.J. Lu 1999-01-22 1:21 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-22 0:48 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:48 ` H.J. Lu @ 1999-01-22 1:21 ` Steinar Bang 1999-01-22 2:01 ` problem building linux specific 1.1.1 Steinar Bang ` (3 more replies) 1999-01-31 23:58 ` H.J. Lu 1 sibling, 4 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-22 1:21 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* problem building linux specific 1.1.1 1999-01-22 1:21 ` Steinar Bang @ 1999-01-22 2:01 ` Steinar Bang 1999-01-22 8:22 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1999-01-22 8:27 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu ` (2 subsequent siblings) 3 siblings, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-22 2:01 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-22 2:01 ` problem building linux specific 1.1.1 Steinar Bang @ 1999-01-22 8:22 ` H.J. Lu 1999-01-25 2:20 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-22 8:22 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-22 8:22 ` H.J. Lu @ 1999-01-25 2:20 ` Steinar Bang 1999-01-25 2:27 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1 sibling, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-25 2:20 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 2:20 ` Steinar Bang @ 1999-01-25 2:27 ` Steinar Bang 1999-01-25 2:49 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-25 2:27 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 2:27 ` Steinar Bang @ 1999-01-25 2:49 ` Steinar Bang 1999-01-25 3:15 ` Andreas Schwab 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-25 2:49 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 2:49 ` Steinar Bang @ 1999-01-25 3:15 ` Andreas Schwab 1999-01-25 3:49 ` Steinar Bang 1999-01-31 23:58 ` Andreas Schwab 1999-01-31 23:58 ` Steinar Bang 1 sibling, 2 replies; 61+ messages in thread From: Andreas Schwab @ 1999-01-25 3:15 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 3:15 ` Andreas Schwab @ 1999-01-25 3:49 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Andreas Schwab 1 sibling, 1 reply; 61+ messages in thread From: Steinar Bang @ 1999-01-25 3:49 UTC (permalink / raw) To: egcs >>>>> 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)) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 3:49 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 0 siblings, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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)) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 3:15 ` Andreas Schwab 1999-01-25 3:49 ` Steinar Bang @ 1999-01-31 23:58 ` Andreas Schwab 1 sibling, 0 replies; 61+ messages in thread From: Andreas Schwab @ 1999-01-31 23:58 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 2:49 ` Steinar Bang 1999-01-25 3:15 ` Andreas Schwab @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 2:27 ` Steinar Bang 1999-01-25 2:49 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 2:20 ` Steinar Bang 1999-01-25 2:27 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-22 8:22 ` H.J. Lu 1999-01-25 2:20 ` Steinar Bang @ 1999-01-31 23:58 ` H.J. Lu 1 sibling, 0 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-31 23:58 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* problem building linux specific 1.1.1 1999-01-22 2:01 ` problem building linux specific 1.1.1 Steinar Bang 1999-01-22 8:22 ` H.J. Lu @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 1:21 ` Steinar Bang 1999-01-22 2:01 ` problem building linux specific 1.1.1 Steinar Bang @ 1999-01-22 8:27 ` H.J. Lu 1999-01-25 1:44 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1999-01-26 10:11 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 3 siblings, 2 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-22 8:27 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > > 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 8:27 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu @ 1999-01-25 1:44 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1 sibling, 1 reply; 61+ messages in thread From: Steinar Bang @ 1999-01-25 1:44 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-25 1:44 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 0 siblings, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 8:27 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu 1999-01-25 1:44 ` Steinar Bang @ 1999-01-31 23:58 ` H.J. Lu 1 sibling, 0 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-31 23:58 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > > 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 1:21 ` Steinar Bang 1999-01-22 2:01 ` problem building linux specific 1.1.1 Steinar Bang 1999-01-22 8:27 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu @ 1999-01-26 10:11 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 3 siblings, 1 reply; 61+ messages in thread From: Steinar Bang @ 1999-01-26 10:11 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-26 10:11 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 0 siblings, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 1:21 ` Steinar Bang ` (2 preceding siblings ...) 1999-01-26 10:11 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 3 siblings, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:48 ` H.J. Lu 1999-01-22 1:21 ` Steinar Bang @ 1999-01-31 23:58 ` H.J. Lu 1 sibling, 0 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-31 23:58 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:42 ` Steinar Bang 1999-01-22 0:48 ` H.J. Lu @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:37 ` H.J. Lu 1999-01-22 0:42 ` Steinar Bang @ 1999-01-22 7:05 ` Andris Pavenis 1999-01-27 9:04 ` Joe Buck 1999-01-31 23:58 ` Andris Pavenis 1999-01-31 23:58 ` H.J. Lu 2 siblings, 2 replies; 61+ messages in thread From: Andris Pavenis @ 1999-01-22 7:05 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 7:05 ` Andris Pavenis @ 1999-01-27 9:04 ` Joe Buck 1999-01-28 0:55 ` Andris Pavenis ` (2 more replies) 1999-01-31 23:58 ` Andris Pavenis 1 sibling, 3 replies; 61+ messages in thread From: Joe Buck @ 1999-01-27 9:04 UTC (permalink / raw) To: Andris Pavenis; +Cc: hjl, egcs > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-27 9:04 ` Joe Buck @ 1999-01-28 0:55 ` Andris Pavenis 1999-01-28 1:16 ` Steinar Bang 1999-01-31 23:58 ` Andris Pavenis 1999-01-29 17:30 ` H.J. Lu 1999-01-31 23:58 ` Joe Buck 2 siblings, 2 replies; 61+ messages in thread From: Andris Pavenis @ 1999-01-28 0:55 UTC (permalink / raw) To: Joe Buck; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-28 0:55 ` Andris Pavenis @ 1999-01-28 1:16 ` Steinar Bang 1999-01-29 3:54 ` Steinar Bang ` (3 more replies) 1999-01-31 23:58 ` Andris Pavenis 1 sibling, 4 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-28 1:16 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-28 1:16 ` Steinar Bang @ 1999-01-29 3:54 ` Steinar Bang 1999-01-29 17:30 ` H.J. Lu 1999-01-29 17:30 ` H.J. Lu ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: Steinar Bang @ 1999-01-29 3:54 UTC (permalink / raw) To: egcs [-- 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 3:54 ` Steinar Bang @ 1999-01-29 17:30 ` H.J. Lu 0 siblings, 0 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-29 17:30 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-28 1:16 ` Steinar Bang 1999-01-29 3:54 ` Steinar Bang @ 1999-01-29 17:30 ` H.J. Lu 1999-01-29 17:58 ` Joe Buck 1999-01-30 1:50 ` Andris Pavenis 1999-01-31 23:58 ` Steinar Bang 3 siblings, 1 reply; 61+ messages in thread From: H.J. Lu @ 1999-01-29 17:30 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 17:30 ` H.J. Lu @ 1999-01-29 17:58 ` Joe Buck 1999-01-29 18:30 ` Jeffrey A Law 0 siblings, 1 reply; 61+ messages in thread From: Joe Buck @ 1999-01-29 17:58 UTC (permalink / raw) To: H.J. Lu; +Cc: sb, egcs 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 17:58 ` Joe Buck @ 1999-01-29 18:30 ` Jeffrey A Law 1999-01-30 2:50 ` Andris Pavenis 1999-01-30 17:37 ` Joe Buck 0 siblings, 2 replies; 61+ messages in thread From: Jeffrey A Law @ 1999-01-29 18:30 UTC (permalink / raw) To: Joe Buck; +Cc: H.J. Lu, sb, egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 18:30 ` Jeffrey A Law @ 1999-01-30 2:50 ` Andris Pavenis 1999-01-30 17:37 ` Joe Buck 1 sibling, 0 replies; 61+ messages in thread From: Andris Pavenis @ 1999-01-30 2:50 UTC (permalink / raw) To: law, Jeffrey A Law, Joe Buck; +Cc: H.J. Lu, sb, egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 18:30 ` Jeffrey A Law 1999-01-30 2:50 ` Andris Pavenis @ 1999-01-30 17:37 ` Joe Buck 1999-01-31 23:58 ` Joe Buck 1 sibling, 1 reply; 61+ messages in thread From: Joe Buck @ 1999-01-30 17:37 UTC (permalink / raw) To: law; +Cc: jbuck, hjl, sb, egcs > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 17:37 ` Joe Buck @ 1999-01-31 23:58 ` Joe Buck 0 siblings, 0 replies; 61+ messages in thread From: Joe Buck @ 1999-01-31 23:58 UTC (permalink / raw) To: law; +Cc: jbuck, hjl, sb, egcs > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-28 1:16 ` Steinar Bang 1999-01-29 3:54 ` Steinar Bang 1999-01-29 17:30 ` H.J. Lu @ 1999-01-30 1:50 ` Andris Pavenis 1999-02-01 2:19 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 3 siblings, 1 reply; 61+ messages in thread From: Andris Pavenis @ 1999-01-30 1:50 UTC (permalink / raw) To: Steinar Bang, egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 1:50 ` Andris Pavenis @ 1999-02-01 2:19 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang 0 siblings, 1 reply; 61+ messages in thread From: Steinar Bang @ 1999-02-01 2:19 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-01 2:19 ` Steinar Bang @ 1999-02-28 22:53 ` Steinar Bang 0 siblings, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-28 1:16 ` Steinar Bang ` (2 preceding siblings ...) 1999-01-30 1:50 ` Andris Pavenis @ 1999-01-31 23:58 ` Steinar Bang 3 siblings, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-28 0:55 ` Andris Pavenis 1999-01-28 1:16 ` Steinar Bang @ 1999-01-31 23:58 ` Andris Pavenis 1 sibling, 0 replies; 61+ messages in thread From: Andris Pavenis @ 1999-01-31 23:58 UTC (permalink / raw) To: Joe Buck; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-27 9:04 ` Joe Buck 1999-01-28 0:55 ` Andris Pavenis @ 1999-01-29 17:30 ` H.J. Lu 1999-01-30 15:50 ` craig 1999-01-31 23:58 ` Joe Buck 2 siblings, 1 reply; 61+ messages in thread From: H.J. Lu @ 1999-01-29 17:30 UTC (permalink / raw) To: Joe Buck; +Cc: egcs > > > 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 17:30 ` H.J. Lu @ 1999-01-30 15:50 ` craig 1999-01-31 12:21 ` H.J. Lu 1999-01-31 23:58 ` craig 0 siblings, 2 replies; 61+ messages in thread From: craig @ 1999-01-30 15:50 UTC (permalink / raw) To: hjl; +Cc: 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 15:50 ` craig @ 1999-01-31 12:21 ` H.J. Lu 1999-02-01 4:48 ` craig 1999-01-31 23:58 ` craig 1 sibling, 1 reply; 61+ messages in thread From: H.J. Lu @ 1999-01-31 12:21 UTC (permalink / raw) To: craig; +Cc: egcs > > >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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-31 12:21 ` H.J. Lu @ 1999-02-01 4:48 ` craig 1999-02-28 22:53 ` craig 0 siblings, 1 reply; 61+ messages in thread From: craig @ 1999-02-01 4:48 UTC (permalink / raw) To: hjl; +Cc: 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-01 4:48 ` craig @ 1999-02-28 22:53 ` craig 0 siblings, 0 replies; 61+ messages in thread From: craig @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 15:50 ` craig 1999-01-31 12:21 ` H.J. Lu @ 1999-01-31 23:58 ` craig 1 sibling, 0 replies; 61+ messages in thread From: craig @ 1999-01-31 23:58 UTC (permalink / raw) To: hjl; +Cc: 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-27 9:04 ` Joe Buck 1999-01-28 0:55 ` Andris Pavenis 1999-01-29 17:30 ` H.J. Lu @ 1999-01-31 23:58 ` Joe Buck 2 siblings, 0 replies; 61+ messages in thread From: Joe Buck @ 1999-01-31 23:58 UTC (permalink / raw) To: Andris Pavenis; +Cc: hjl, egcs > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 7:05 ` Andris Pavenis 1999-01-27 9:04 ` Joe Buck @ 1999-01-31 23:58 ` Andris Pavenis 1 sibling, 0 replies; 61+ messages in thread From: Andris Pavenis @ 1999-01-31 23:58 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-22 0:37 ` H.J. Lu 1999-01-22 0:42 ` Steinar Bang 1999-01-22 7:05 ` Andris Pavenis @ 1999-01-31 23:58 ` H.J. Lu 2 siblings, 0 replies; 61+ messages in thread From: H.J. Lu @ 1999-01-31 23:58 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > > >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-21 23:48 ` Steinar Bang 1999-01-22 0:37 ` H.J. Lu @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-21 2:44 ` Steinar Bang 1999-01-21 23:48 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs >>>>> 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). ^ permalink raw reply [flat|nested] 61+ messages in thread
* multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-21 0:36 multiple definitions of 'xxx keyed to...' in egcs-1.1.1 Steinar Bang 1999-01-21 2:44 ` Steinar Bang @ 1999-01-31 23:58 ` Steinar Bang 1 sibling, 0 replies; 61+ messages in thread From: Steinar Bang @ 1999-01-31 23:58 UTC (permalink / raw) To: egcs 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 @ 1999-01-25 5:41 N8TM 1999-01-31 23:58 ` N8TM 0 siblings, 1 reply; 61+ messages in thread From: N8TM @ 1999-01-25 5:41 UTC (permalink / raw) To: sb, egcs In a message dated 1/25/99 3:53:51 AM Pacific Standard Time, sb@metis.no writes: << Hm... I have patch 2.1 it seems. At least that's what "patch -v" reports. >> patch-2.1 was working for me when I installed egcs-1.1.1 on linux-gnulibc1 and Irix6.4, but it failed on recent snapshots, so I've switched to patch-2.5. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: problem building linux specific 1.1.1 1999-01-25 5:41 problem building linux specific 1.1.1 N8TM @ 1999-01-31 23:58 ` N8TM 0 siblings, 0 replies; 61+ messages in thread From: N8TM @ 1999-01-31 23:58 UTC (permalink / raw) To: sb, egcs In a message dated 1/25/99 3:53:51 AM Pacific Standard Time, sb@metis.no writes: << Hm... I have patch 2.1 it seems. At least that's what "patch -v" reports. >> patch-2.1 was working for me when I installed egcs-1.1.1 on linux-gnulibc1 and Irix6.4, but it failed on recent snapshots, so I've switched to patch-2.5. ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~1999-02-28 22:53 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-01-21 0:36 multiple definitions of 'xxx keyed to...' in egcs-1.1.1 Steinar Bang 1999-01-21 2:44 ` Steinar Bang 1999-01-21 23:48 ` Steinar Bang 1999-01-22 0:37 ` H.J. Lu 1999-01-22 0:42 ` Steinar Bang 1999-01-22 0:48 ` H.J. Lu 1999-01-22 1:21 ` Steinar Bang 1999-01-22 2:01 ` problem building linux specific 1.1.1 Steinar Bang 1999-01-22 8:22 ` H.J. Lu 1999-01-25 2:20 ` Steinar Bang 1999-01-25 2:27 ` Steinar Bang 1999-01-25 2:49 ` Steinar Bang 1999-01-25 3:15 ` Andreas Schwab 1999-01-25 3:49 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Andreas Schwab 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1999-01-22 8:27 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu 1999-01-25 1:44 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1999-01-26 10:11 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1999-01-22 7:05 ` Andris Pavenis 1999-01-27 9:04 ` Joe Buck 1999-01-28 0:55 ` Andris Pavenis 1999-01-28 1:16 ` Steinar Bang 1999-01-29 3:54 ` Steinar Bang 1999-01-29 17:30 ` H.J. Lu 1999-01-29 17:30 ` H.J. Lu 1999-01-29 17:58 ` Joe Buck 1999-01-29 18:30 ` Jeffrey A Law 1999-01-30 2:50 ` Andris Pavenis 1999-01-30 17:37 ` Joe Buck 1999-01-31 23:58 ` Joe Buck 1999-01-30 1:50 ` Andris Pavenis 1999-02-01 2:19 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Andris Pavenis 1999-01-29 17:30 ` H.J. Lu 1999-01-30 15:50 ` craig 1999-01-31 12:21 ` H.J. Lu 1999-02-01 4:48 ` craig 1999-02-28 22:53 ` craig 1999-01-31 23:58 ` craig 1999-01-31 23:58 ` Joe Buck 1999-01-31 23:58 ` Andris Pavenis 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-31 23:58 ` Steinar Bang 1999-01-25 5:41 problem building linux specific 1.1.1 N8TM 1999-01-31 23:58 ` N8TM
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).