This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
- To: law at cygnus dot com
- Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 15 Jul 1999 05:13:57 -0300
- Cc: Richard Henderson <rth at cygnus dot com>, egcs-bugs at egcs dot cygnus dot com, egcs-patches at egcs dot cygnus dot com
- References: <14182.931940172@upchuck.cygnus.com> <orr9mav362.fsf@cupuacu.lsd.dcc.unicamp.br>
On Jul 15, 1999, Alexandre Oliva <oliva@dcc.unicamp.br> wrote:
> I see... That's a good reason for not installing the patch for gcc
> 2.95, unless we'd promise not to change it in the future.
Which is not really that bad, after thinking about it for a while...
I can't think of any bad side-effect of copying all symbols of libgcc
into a shared libstdc++, except for a small increase in size of
libstdc++, which is quickly compensated by the reduction in size of
executables linked with it. Of course, such executables won't run
with older versions of libstdc++, but do we care? As long as they run
with newer versions of libstdc++, everything is fine and, in fact,
this change *improves* on libstdc++, because then it could be upgraded
without the risk of breaking old applications because of minor changes
in exception handling mechanisms, for example.
> may I mention it in the specific.html web page, along with the
> possible negative consequences of it?
Well, if you agree with this, just approve this patch:
Index: install/dec-osf-shlibstdc++.patch
===================================================================
RCS file: dec-osf-shlibstdc++.patch
diff -N dec-osf-shlibstdc++.patch
--- install/dec-osf-shlibstdc++.patch Sat Dec 5 20:30:03 1998
+++ install/dec-osf-shlibstdc++.patch Thu Jul 15 01:12:48 1999
@@ -0,0 +1,27 @@
+Index: libstdc++/ChangeLog
+from Alexandre Oliva <oliva@dcc.unicamp.br>
+
+ * config/dec-osf.ml: Force all of libgcc into libstdc++, to avoid
+ multiply-defined linker errors.
+
+Index: libstdc++/config/dec-osf.ml
+===================================================================
+RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/config/dec-osf.ml,v
+retrieving revision 1.2
+diff -u -r1.2 dec-osf.ml
+--- libstdc++/config/dec-osf.ml 1998/08/30 21:18:41 1.2
++++ libstdc++/config/dec-osf.ml 1999/07/15 07:40:11
+@@ -3,4 +3,12 @@
+
+ LIBS = $(ARLIB) $(ARLINK) $(SHLIB) $(SHLINK)
+ DEPLIBS = ../$(SHLIB)
+-SHDEPS = -lm
++SHDEPS = -lm -Wl,-all,-lgcc,-none
++# Some testcases in the testsuite required symbols from libgcc, say,
++# __pure_virtual, that would not have been copied into libstdc++
++# without this -Wl switch above. But __pure_virtual depended on other
++# symbols of libgcc that had been copied to libstdc++. However,
++# DU4.0d's ld would report such symbols as duplicates, and refuse to
++# link. Forcing some symbols from libgcc into libstdc++ ensures that
++# we don't get such late undefined symbols, avoiding the bogus
++# multiple-definition errors.
Index: install/specific.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/install/specific.html,v
retrieving revision 1.37
diff -u -r1.37 specific.html
--- install/specific.html 1999/07/12 23:44:32 1.37
+++ install/specific.html 1999/07/15 08:12:48
@@ -117,6 +117,46 @@
compiler, you would use `<code>udk-gcc</code>'. They will coexist peacefully with
any native-target EGCS tools you may have installed.
+<p><b>alpha*-dec-osf*</b><br>
+If you install a shared libstdc++ and, when you link a non-trivial C++
+program (for example, <code>gcc/testsuite/g++.other/delete3.C</code>),
+the linker reports a couple of errors about multiply-defined symbols
+(for example, <code>nothrow</code>, <code>__throw</code> and
+<code>terminate(void)</code>), you've probably got a linker bug, for
+which there's no known fix. The officially recommended work-around is
+to remove the shared libstdc++.
+
+<p>An alternative solution is to arrange that all symbols from
+<code>libgcc</code> get copied to the shared <code>libstdc++</code>;
+see detailed solution below. (Surprising as it may seem, this does
+indeed fix the problem!) <b>Beware</b> that this may bring you
+binary-compatibility problems in the future, if you don't use the same
+work-around next time you build <code>libstdc++</code>: if programs
+start to depend on <code>libstdc++</code> to provide symbols that used
+to be only in <code>libgcc</code>, you must arrange that
+<code>libstdc++</code> keeps providing them, otherwise the programs
+will have to be relinked.
+
+<p>The magic spell is to add <code>-Wl,-all,-lgcc,-none</code> to the
+definition of macro <code>SHDEPS</code> in
+<code>libstdc++/config/dec-osf.ml</code> <b>before</b>
+<code>alpha*-dec-osf*/libstdc++/Makefile</code> is created (a <a
+href="dec-osf-shlibstdc++.patch">patch</a> that does just that is
+available). If the Makefile already exists, run
+<code>./config.status</code> within directory
+<code>alpha*-dec-osf*/libstdc++</code> (and
+<code>alpha*-dec-osf*/ieee/libstdc++</code>, if it also exists).
+Remove any existing <code>libstdc++.so*</code> from such directories,
+and run <code>make all-target-libstdc++</code> in the top-level
+directory, then <code>make install-target-libstdc++</code>.
+
+<p>If you have already removed the build tree, you may just remove
+<code>libstdc++.so.2.10.0</code> from the install tree and re-create
+it with the command <code>gcc -shared -o libstdc++.so.2.10.0
+-Wl,-all,-lstdc++,-lgcc,-none -lm</code>. If the <code>ieee</code>
+sub-directory exists, repeat this command in it, with the additional
+flag <code>-mieee</code>.
+
<p><b>hppa*-hp-hpux*</b><br>
We <b>highly</b> recommend using gas/binutils-2.8 or newer on all hppa
platforms; you may encounter a variety of problems when using the HP assembler.
@@ -256,7 +296,7 @@
will be discarded automatically.
<hr>
-<i>Last modified on July 12, 1999.</i>
+<i>Last modified on July 15, 1999.</i>
</body>
</html>
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them