This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ libtool lossage
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "java-patches at gcc dot gnu dot org" <java-patches at gcc dot gnu dot org>
- Date: 24 Feb 2002 17:06:21 -0300
- Subject: Re: libstdc++ libtool lossage
- Organization: GCC Team, Red Hat
- References: <61170000.1014578198@warlock.codesourcery.com>
On Feb 24, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
> 0. I kind of wish that shared libraries had never been invented. They
> have ruined my Sunday morning.
:-)
> a. Make -shared-libgcc behave differently when linking a shared
> library from the creation of a final executable. (Now that
> I understand the problem, I see that this was Alexandre's
> suggestion. That we arrived at the same solution independently
> is perhaps a good indication that it is a decent idea.)
Great.
> Therefore, I'll pre-approve Alexandre's proposed change. Alexandre,
> please also add documentation explaining what "-shared-libgcc" does
> in both the shared library and final link contexts.
I won't take advantage of pre-approval because of the style in which
I've written the specs. I'd like explicit approval to introduce this
in GCC, since it does not follow GNU Coding Standards, even though I
found this arrangement helpful to keep track of the nesting of specs.
> Since we have a solution that I am confident will work, I will create
> the branch tomorrow, providing that the SPARC problem has been fixed.
> (Has it?)
The patch I posted this morning has completed bootstrapping on
sparc-sun-solaris2.7, and is now building libjava.
sparcv9-sun-solaris2.7 is approaching completion of bootstrap. As
soon as it does, I'll officially submit the patch.
Index: gcc/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* gcc.c (init_gcc_specs): Get -shared-libgcc along with -shared to
link with shared_name only.
* doc/invoke.texi (Link Options): Document new behavior.
Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/gcc.c,v
retrieving revision 1.295
diff -u -p -r1.295 gcc.c
--- gcc/gcc.c 2002/02/23 05:59:47 1.295
+++ gcc/gcc.c 2002/02/24 20:00:50
@@ -1414,31 +1414,44 @@ init_gcc_specs (obstack, shared_name, st
const char *static_name;
const char *eh_name;
{
- char buffer[128];
- const char *p;
+#undef ADD
+#define ADD(s) obstack_grow (obstack, s, strlen (s))
- /* If we see -shared-libgcc, then use the shared version. */
- sprintf (buffer, "%%{shared-libgcc:%s %s}", shared_name, static_name);
- obstack_grow (obstack, buffer, strlen (buffer));
- /* If we see -static-libgcc, then use the static version. */
- sprintf (buffer, "%%{static-libgcc:%s %s}", static_name, eh_name);
- obstack_grow (obstack, buffer, strlen (buffer));
- /* Otherwise, if we see -shared, then use the shared version
- if using EH registration routines or static version without
- exception handling routines otherwise. */
- p = "%{!shared-libgcc:%{!static-libgcc:%{shared:";
- obstack_grow (obstack, p, strlen (p));
+ ADD ("%{!shared:"); {
+ ADD ("%{!shared-libgcc:"); {
+ ADD (static_name);
+ ADD (" ");
+ ADD (eh_name);
+ } ADD ("}");
+ ADD ("%{shared-libgcc:"); {
+ ADD (shared_name);
+ ADD (" ");
+ ADD (static_name);
+ } ADD ("}");
+ } ADD ("}");
+
+ ADD ("%{shared:"); {
+ ADD ("%{static-libgcc:"); {
+ ADD (static_name);
+ ADD (" ");
+ ADD (eh_name);
+ } ADD ("}");
+ ADD ("%{!static-libgcc:"); {
+ ADD ("%{shared-libgcc:"); {
+ ADD (shared_name);
+ } ADD ("}");
+ ADD ("%{!shared-libgcc:"); {
#ifdef LINK_EH_SPEC
- sprintf (buffer, "%s}}}", static_name);
+ ADD (static_name);
#else
- sprintf (buffer, "%s}}}", shared_name);
+ ADD (shared_name);
#endif
- obstack_grow (obstack, buffer, strlen (buffer));
- /* Otherwise, use the static version. */
- sprintf (buffer,
- "%%{!shared-libgcc:%%{!static-libgcc:%%{!shared:%s %s}}}",
- static_name, eh_name);
- obstack_grow (obstack, buffer, strlen (buffer));
+ } ADD ("}");
+ } ADD ("}");
+ } ADD ("}");
+
+#undef ADD
+
}
#endif /* ENABLE_SHARED_LIBGCC */
Index: gcc/doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/doc/invoke.texi,v
retrieving revision 1.118
diff -u -p -r1.118 invoke.texi
--- gcc/doc/invoke.texi 2002/02/23 17:10:30 1.118
+++ gcc/doc/invoke.texi 2002/02/24 20:00:59
@@ -4428,15 +4428,26 @@ of these is when the application wishes
across different shared libraries. In that case, each of the libraries
as well as the application itself should use the shared @file{libgcc}.
-Therefore, whenever you specify the @option{-shared} option, the GCC
-driver automatically adds @option{-shared-libgcc}, unless you explicitly
-specify @option{-static-libgcc}. The G++ driver automatically adds
-@option{-shared-libgcc} when you build a main executable as well because
-for C++ programs that is typically the right thing to do.
-(Exception-handling will not work reliably otherwise.)
+Therefore, the G++ and GCJ drivers automatically add
+@option{-shared-libgcc} whenever you build a shared library or a main
+executable, because C++ and Java programs typically use exceptions, so
+this is the right thing to do.
-However, when linking a main executable written in C, you must
-explicitly say @option{-shared-libgcc} if you want to use the shared
+If, instead, you use the GCC driver to create shared libraries, you may
+find that the shared version of @file{libgcc} is not always linked in.
+If GCC finds, at its configuration time, that you have a GNU linker that
+does not support option @option{--eh-frame-hdr}, it will link the shared
+version of @file{libgcc} into shared libraries by default. Otherwise,
+it will take advantage of the linker and optimize away the linking with
+the shared version of @file{libgcc}, linking with the static version of
+libgcc by default. This allows exceptions to propagate through such
+shared libraries, without incurring relocation costs at library load
+time.
+
+However, if a library or main executable is supposed to throw or catch
+exceptions, you must link it using the G++ or GCJ driver, as appropriate
+for the languages used in the program, or using the option
+@option{-shared-libgcc}, such that it is linked with the shared
@file{libgcc}.
@item -symbolic
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer