libstdc++ libtool lossage

[Alexandre Oliva]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-shared-libgcc.patch
Type: text/x-patch
Size: 4696 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020224/b3d0797e/attachment.bin>
-------------- next part --------------

-- 
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