shared libstdc++ is broken on alphaev56-dec-osf4.0d

shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

Richard, it seems that the following patch broke shared library
construction on alpha-dec-osf4.0:

Mon Jun 21 20:10:42 1999  Richard Henderson  <rth@cygnus.com>

	* collect2.c (main): Log frame table count.
	(GCC_OK_SYMBOL) [ECOFF]: Accept stGlobal.
	(scan_prog_file) [COFF]: Handle frame tables.

If I revert it and rebuild libstdc++.so, several C++ testcases that
have recently started to FAIL with errors like the ones below PASS
again.

FAIL: g++.brendan/nest21.C (test for excess errors)
/usr/bin/ld:
/usr/local/tmp/egcs/gcc/libgcc.a(_eh.o): _GLOBAL_$F$__default_terminate: multiply defined
/usr/local/tmp/egcs/gcc/libgcc.a(frame.o): __register_frame_info_table: multiply defined
/usr/local/tmp/egcs/gcc/libgcc.a(frame.o): __deregister_frame_info: multiply defined

I don't know what you intended to fix with this patch, so I won't try
to fix it (unless you try to explain it to me, but it would probably
be useless :-)

Hope this helps.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Jeffrey A Law]

  In message < 19990706102351.A2416@cygnus.com >you write:
  > On Mon, Jul 05, 1999 at 10:52:02AM -0300, Alexandre Oliva wrote:
  > > Richard, it seems that the following patch broke shared library
  > > construction on alpha-dec-osf4.0:
  > > 
  > > Mon Jun 21 20:10:42 1999  Richard Henderson  <rth@cygnus.com>
  > > 
  > > 	* collect2.c (main): Log frame table count.
  > > 	(GCC_OK_SYMBOL) [ECOFF]: Accept stGlobal.
  > > 	(scan_prog_file) [COFF]: Handle frame tables.
  > 
  > Without this patch, absolutely no EH works, staticly linked
  > or otherwise.
  > 
  > > FAIL: g++.brendan/nest21.C (test for excess errors)
  > > /usr/bin/ld:
  > > /usr/local/tmp/egcs/gcc/libgcc.a(_eh.o): \
  > > _GLOBAL_$F$__default_terminate: multiply defined
  > 
  > So we need to somehow prevent libgcc symbols from being exported
  > from the shared library.  I don't know DU well enough to know if
  > that's possible.
This is a long-standing known issue (the need to control which symbols are
exported from libgcc).  It's something I'd like to see a good solution for
one day for reasonable object formats.

jeff

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Jeffrey A Law]

  In message < 3783a0b1.350010406@mailer.gwdg.de >you write:
  > On Tue, 06 Jul 1999 23:31:46 -0600, Jeffrey A Law <law@cygnus.com>
  > wrote:
  > 
  > >This is a long-standing known issue (the need to control which symbols are
  > >exported from libgcc).
  > 
  > If binutils would work on every platform, I'd propose using symbol
  > versioning like glibc2 does. That would a) bring us versioned symbols
  > (not quite so important because libgcc is static) but b) would allow
  > for easy hiding.
  > 
  > Or is it more of a question of what to hide then of how ?
You can't assume binutils works on every platform.  You can't even assume that
if binutils works that people will be using it.

Even if binutils works on every platform, not every system uses an object file
format which has these kinds of capabilities.

So, you have to actually test for the features you need during the configure
process and if they are present, then you can use versioning or whatever scheme
to avoid undesirable exporting of symbols from libgcc.

jeff

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

On Jul  6, 1999, Richard Henderson <rth@cygnus.com> wrote:

> On Mon, Jul 05, 1999 at 10:52:02AM -0300, Alexandre Oliva wrote:
>> Richard, it seems that the following patch broke shared library
>> construction on alpha-dec-osf4.0:
>> 
>> Mon Jun 21 20:10:42 1999  Richard Henderson  <rth@cygnus.com>
>> 
>> * collect2.c (main): Log frame table count.
>> (GCC_OK_SYMBOL) [ECOFF]: Accept stGlobal.
>> (scan_prog_file) [COFF]: Handle frame tables.

> Without this patch, absolutely no EH works, staticly linked
> or otherwise.

I see...

>> FAIL: g++.brendan/nest21.C (test for excess errors)
>> /usr/bin/ld:
>> /usr/local/tmp/egcs/gcc/libgcc.a(_eh.o): \
>> _GLOBAL_$F$__default_terminate: multiply defined

> So we need to somehow prevent libgcc symbols from being exported
> from the shared library.  I don't know DU well enough to know if
> that's possible.

It is.  I've just been able to build a shared libstdc++ that passes
all tests by appending: 

'-Wl,-hidden_symbol,__throw,-hidden_symbol,__register_frame_info_table,-hidden_symbol,__deregister_frame_info,-hidden_symbol,_GLOBAL_$$F$$__default_terminate'

to libstdc++/config/dec-osf.ml's SHDEPS.

However, I recall Jeff having discussed with me the issue of hiding
symbols in a shared library, and he convinced me it was not the way to
go, because functions within the shared library would refer to the
internal, hidden symbol, whereas functions in other libraries would
refer to the symbols from libgcc, which would not be unified with the
hidden ones, so things would break.

Anyway, I've just noticed that our current libstdc++ build produces
the following warning while linking the shared libstdc++:

/usr/bin/ld:
Warning: Unresolved:
__throw

I don't understand why this happens, but it is indeed true that
libstdc++ does not have a definition for __throw:

oliva@bela% nm libstdc++.so | grep __throw
                 U __throw
000003ffbff91190 T __throw_bad_cast
000003ffbff91550 T __throw_bad_typeid
000003ffbff94930 T __throw_type_match
000003ffbff94cd0 T __throw_type_match_rtti

Since AFAIK the only reason to link libgcc into the shared libstdc++
is to ensure that it's complete, so that it can be dlopened, but this
is not currently accomplished, I suggest that we simply stop linking
libstdc++ with libgcc, so that we can at least release gcc 2.95 with a
working shared libstdc++ on alpha-dec-osf4.0d, and then we can worry
about the symbol exporting problem later.

Jeff, is this ok for the release branch?  (Maybe for mainline too?)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{guarana.com,{gnu,kaffe,samba}.org,{egcs,sourceware}.cygnus.com}
*** E-mail about software projects will be forwarded to mailing lists
>From oliva@dcc.unicamp.br Sat Jul 10 01:51:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Daniel Jacobowitz <drow@false.org>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: g++ gives gratuitous "will use a temporary" warnings in CVS 19990611
Date: Sat, 10 Jul 1999 01:51:00 -0000
Message-id: <oroghkkhuh.fsf@cupuacu.lsd.dcc.unicamp.br>
References: <19990710042745.A29341@drow.res.cmu.edu>
X-SW-Source: 1999-07/msg00388.html
Content-length: 449

On Jul 10, 1999, Daniel Jacobowitz <drow@false.org> wrote:

> The attached test program shows a warning regression in g++:

Err...  Which attached test program?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{guarana.com,{gnu,kaffe,samba}.org,{egcs,sourceware}.cygnus.com}
*** E-mail about software projects will be forwarded to mailing lists

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Jeffrey A Law]

  In message < orwvw8khxu.fsf@cupuacu.lsd.dcc.unicamp.br >you write:
  > However, I recall Jeff having discussed with me the issue of hiding
  > symbols in a shared library, and he convinced me it was not the way to
  > go, because functions within the shared library would refer to the
  > internal, hidden symbol, whereas functions in other libraries would
  > refer to the symbols from libgcc, which would not be unified with the
  > hidden ones, so things would break.
  > 
  > Anyway, I've just noticed that our current libstdc++ build produces
  > the following warning while linking the shared libstdc++:
  > 
  > /usr/bin/ld:
  > Warning: Unresolved:
  > __throw
  > 
  > I don't understand why this happens, but it is indeed true that
  > libstdc++ does not have a definition for __throw:
  > 
  > oliva@bela% nm libstdc++.so | grep __throw
  >                  U __throw
  > 000003ffbff91190 T __throw_bad_cast
  > 000003ffbff91550 T __throw_bad_typeid
  > 000003ffbff94930 T __throw_type_match
  > 000003ffbff94cd0 T __throw_type_match_rtti
  > 
  > Since AFAIK the only reason to link libgcc into the shared libstdc++
  > is to ensure that it's complete, so that it can be dlopened, but this
  > is not currently accomplished, I suggest that we simply stop linking
  > libstdc++ with libgcc, so that we can at least release gcc 2.95 with a
  > working shared libstdc++ on alpha-dec-osf4.0d, and then we can worry
  > about the symbol exporting problem later.
  > 
  > Jeff, is this ok for the release branch?  (Maybe for mainline too?)
No.  I don't want to make this change, particularly this late in the
cycle.  We're just exchanging one set of known problems for a set of
unknown problems.  Not something we want to do at this stage.

We can evaluate it for the mainline, but it's something rth or the
other osf1 gurus will need to get involved with.

jeff
>From vbar@comp.cz Sun Jul 11 00:53:00 1999
From: Vaclav Barta <vbar@comp.cz>
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: can't pass pointers to template functions as arguments
Date: Sun, 11 Jul 1999 00:53:00 -0000
Message-id: <37883288.78A69741@comp.cz>
References: <3787295B.E2912804@comp.cz> <199907101719.TAA12327@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-07/msg00413.html
Content-length: 1160

Martin v. Loewis wrote:
> 
> > I want to templatize a conversion from exception-throwing function
> > to error-returning function. But, when I try to instantiate my
> > function template by passing the function name as a parameter of
> > another function, egcs crashes. I'm not quite sure what I'm trying
> > to do is legal, but even if it isn't, the compiler should IMHO say
> > so.
> 
> Thanks for your bug report. gcc-2.95 19990701 says
> 
> safecall.cc: In function `TReturn SafeCall()':
> safecall.cc:5: default argument for template parameter in function template `SafeCall()'
> safecall.cc: In function `int main()':
> safecall.cc:26: no matches converting function `SafeCall' to type `int (*)()'
> safecall.cc:5: candidates are: template <class TReturn, TReturn (* ThrowingFunction)(), TReturn ErrorCode> TReturn SafeCall()
> 
> so it appears that the bug has been fixed.
I probably don't understand. The instantiation of SafeCall for
TReturn = int *has* type int (*)() . If I can do
    int (*p)() = SafeCall<int, Callback>;
(which does compile) why not
    int LibraryFunction(int (*p)());
    LibraryFunction(SafeCall<int, Callback>);

	Bye
		Vasek
>From jdassen@wi.leidenuniv.nl Sun Jul 11 04:29:00 1999
From: "J.H.M. Dassen" <jdassen@wi.leidenuniv.nl>
To: egcs-bugs@egcs.cygnus.com
Cc: 33786@bugs.debian.org
Subject: Internal compiler error in `float_signal'
Date: Sun, 11 Jul 1999 04:29:00 -0000
Message-id: <19990711132900.B3336@pc203a.wi.leidenuniv.nl>
X-SW-Source: 1999-07/msg00414.html
Content-length: 719

[Please Cc: 33786@bugs.debian.org so your responses get archived in the
Debian bugtracking system]

This problem is still repeatable with 
	gcc version gcc-2.95 19990625 (prerelease)

jcn206a ray 13:23 /tmp > /usr/lib/gcc-ss/bin/gcc -O1 -o funnyO1 funny.c &&
./funnyO1                                                                           
funny.c: In function `main':
funny.c:14: Internal compiler error in `float_signal', at toplev.c:2418

Ray
-- 
LEADERSHIP  A form of self-preservation exhibited by people with auto-
destructive imaginations in order to ensure that when it comes to the crunch 
it'll be someone else's bones which go crack and not their own.       
- The Hipcrime Vocab by Chad C. Mulligan    
>From martin@mira.isdn.cs.tu-berlin.de Sun Jul 11 04:53:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: vbar@comp.cz
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: can't pass pointers to template functions as arguments
Date: Sun, 11 Jul 1999 04:53:00 -0000
Message-id: <199907111144.NAA00574@mira.isdn.cs.tu-berlin.de>
References: <3787295B.E2912804@comp.cz> <199907101719.TAA12327@mira.isdn.cs.tu-berlin.de> <37883288.78A69741@comp.cz>
X-SW-Source: 1999-07/msg00415.html
Content-length: 583

> Sender: vb@vega.inec.cz
> > safecall.cc: In function `TReturn SafeCall()':
> > safecall.cc:5: default argument for template parameter in function template `SafeCall()'

> I probably don't understand.

Please look at the first error first. The C++ standard says

  /* [temp.param] 

     A default template-argument shall not be specified in a
     function template declaration or a function template definition, nor
     in the template-parameter-list of the definition of a member of a
     class template.  */

If you fix this, gcc 2.95 will compile your code.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Sun Jul 11 05:03:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: oliva@dcc.unicamp.br
Cc: dvv@dvv.ru, egcs-bugs@egcs.cygnus.com
Subject: Re: what is wrong here?
Date: Sun, 11 Jul 1999 05:03:00 -0000
Message-id: <199907111158.NAA00603@mira.isdn.cs.tu-berlin.de>
References: <377d22f9.20361699@localhost> <orzp1fmzuz.fsf@cacau.lsd.dcc.unicamp.br> <377e4751.29668249@localhost> <org137cztw.fsf@cupuacu.lsd.dcc.unicamp.br> <199907031214.OAA00686@mira.isdn.cs.tu-berlin.de> <oremip37hu.fsf@cupuacu.lsd.dcc.unicamp.br> <199907040924.LAA00573@mira.isdn.cs.tu-berlin.de> <oryagv908m.fsf@cupuacu.lsd.dcc.unicamp.br>
X-SW-Source: 1999-07/msg00416.html
Content-length: 1899

> > However, if that was the case: Why is it allowed that two using
> > declarations introduce two functions with identical parameter lists?
> 
> This is just a guess: Maybe because functions can be overloaded, and
> there's no way fro a using declaration to select a subset of the
> declarations of an overloaded function.

That was a rhetorical question, sorry. A declaration of a friend
function is only a re-declaration if there was a prior declaration of
that function as a member of the enclosing namespace.

You seem to assume that a using-declaration makes the functions
denoted members of the namespace. If that was the case, then you would
get violations of the odr. So the logical consequence is that
using-declarations do not declare the functions as namespace members.

Otherwise, is the following text well-formed?

namespace A{void foo(){}}
namespace B{void foo(){}}
namespace C{using A::foo;using B::foo;class Bar{friend void foo();};}

My interpretation is: Yes, it is, but C::foo is not defined, yet.

> > namespace X{ void foo(); }
> > namespace Y{ using X::foo; class Bar{ friend void foo(){} }; }
> 
> > Following your line of reasoning, this should define X::foo. I hope
> > this is not the case, though.
> 
> According to my line of reasoning, this would be invalid because
> X::foo can only be defined in namespace X or in some enclosing
> namespace.  However, I can't seem to find the restriction that a
> non-member function can only be defined in enclosing namepaces in the
> Standard at this very moment; am I mistaken?


It is in 7.3.1.2, [namespace.memdef]/2. However, this rule does not
strictly apply: the member is not defined by explicit qualification.

I still think that the original example

void foo();

namespace B{
  using ::foo;
  class X{
    friend void foo();
    int x;
  };
}

void foo(){
  X x;x.x=3;
}

is ill-formed in standard C++.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Sun Jul 11 05:48:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: klaas@kite.rhein-main.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Faulty compiler output compiling a C++ file with overloaded function
Date: Sun, 11 Jul 1999 05:48:00 -0000
Message-id: <199907111242.OAA00802@mira.isdn.cs.tu-berlin.de>
References: <19990709225025.A1478@kite.compuserve.com>
X-SW-Source: 1999-07/msg00418.html
Content-length: 316

> A function that is overloaded (not a member of a class) causes the
> compiler to generate (apparently) invalid code and the link phase
> fails:

Thanks for your bug report. I could not reproduce it with
egcs-2.91.66, so it appears that the bug has been fixed.
gcc-2.95 also had no problems here.

Regards,
Martin

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

On Jul 10, 1999, Jeffrey A Law <law@cygnus.com> wrote:

>   In message < orwvw8khxu.fsf@cupuacu.lsd.dcc.unicamp.br >you write:

>> Since AFAIK the only reason to link libgcc into the shared libstdc++
>> is to ensure that it's complete, so that it can be dlopened, but this
>> is not currently accomplished, I suggest that we simply stop linking
>> libstdc++ with libgcc, so that we can at least release gcc 2.95 with a
>> working shared libstdc++ on alpha-dec-osf4.0d, and then we can worry
>> about the symbol exporting problem later.

>> Jeff, is this ok for the release branch?  (Maybe for mainline too?)

> No.  I don't want to make this change, particularly this late in the
> cycle.  We're just exchanging one set of known problems for a set of
> unknown problems.

But a *very serious* set of known problems.  The way it is now,
libstdc++ on OSF4/alpha is useless for any non-trivial C++ program.
:-(

Another option would be to link libgcc into libstdc++.so with -all (so
that all objects of libgcc are copied into the shared library), and
arrange that g++ doesn't link with -lgcc in addition to -lstdc++.  But
IMHO this would be much more dangerous than the very simple
work-around I'm suggesting.

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

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

On Jul 13, 1999, Jeffrey A Law <law@cygnus.com> wrote:

> Sorry.  This is not going into this release.  First and foremost,
> the change is wrong.  Shared libraries need to be self-contained.

As I explained in my previous e-mail, libstdc++.so is *not*
self-contained on my system, at this point, because __throw is not
copied from libgcc.a, for some reason I don't understand, but it is a
fact.  So libstdc++.so *is* currently broken.  I'm just trying to
arrange that it at least works on its own.

[Time passes...]

I've just checked libstdc++.so again, and, to my surprise, it is
indeed complete.  I don't know what mistake I made when I verified it
was not, just before submitting my patch, but now that I see it is
indeed complete, I agree the patch I posted is not the way to go.


> Thus it is not acceptable to simply remove libgcc from a shared
> library link line.

How about linking the entire libgcc.a into libstdc++.so, with `-all
-lgcc', so that g++ doesn't explicitly link with -lgcc?  Would that be 
reasonable for 2.95.1?


> What we have to do (not for gcc-2.95) is find a way to prevent
> shared libraries from re-exporting symbols they get from libgcc.

AFAICT, there are only three ways to prevent this: (i) link with
`-hidden -lgcc', so that symbols from libgcc are made local to the
shared library; this is a problem because then we can have multiple
separate definitions of the same symbols; or (ii) arrange that libgcc
is shared, so that symbols are not copied, but libstdc++ is noted to
depend on libgcc; I know there are reasons to prefer not to do it.  So 
I don't see any way out :-(


But wait!  Instead of trying to hide the problem, I tried to find out
why it happened.  It turned out that, if I forced certain symbols from
libgcc to be copied to libstdc++ (for example, __pure_virtual, used by
nest21.C), the multiple-definition errors would stop being flagged!
It appears that, when the linker gets to libgcc looking for
__pure_virtual, other symbols referred in that object file become
`undefined', even though they're present in libstdc++ that had already 
been scanned.  But then, when it finds the symbols in libgcc.a, it
``remembers'' they were already defined in libstdc++.so, and reports
them as duplicates.  A linker bug.  :-(

Fortunately, the work around is straightforward.  Attached is a
candidate patch, that has produced good results in initial testing.
I'm running check at this very moment, but I have to leave before it
finishes, so it may turn out that one or two additional symbols would
be needed.  How does this look for 2.95?

-- 
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
>From law@cygnus.com Tue Jul 13 17:15:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: joel@OARcorp.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: sh-rtems FAILS on egcs-1990629 
Date: Tue, 13 Jul 1999 17:15:00 -0000
Message-id: <12929.931911268@upchuck.cygnus.com>
References: <Pine.LNX.4.10.9907131231280.2629-100000@oar3remote>
X-SW-Source: 1999-07/msg00502.html
Content-length: 839

  In message < Pine.LNX.4.10.9907131231280.2629-100000@oar3remote >you write:
  > 
  > Hi,
  > 
  > This configuration built successfully under egcs 1.1.2 so something has
  > broken. :(
Hmm, I thought we had checked in a fix for this bug long ago.


Hmm, can you extract this fix from the mainline tree and see if it solves your
problem?

Fri Jun  4 03:20:40 1999  J"orn Rennecke <amylaar@cygnus.co.uk>

        * sh.c (fixup_addr_diff_vecs): Emit braf reference label.
        (braf_label_ref_operand): Delete.
        * sh.h (PREDICATE_CODES): Remove braf_label_ref_operand.
        * sh.md (casesi_jump_2): Operand1 is now the inside of a
        label_ref, and has no predicate.
        The patten has a predicate to guard against invalid substitutions.
        (dummy_jump): Delete.
        (casesi): Update use of casesi_jump_2.

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Richard Henderson]

On Mon, Jul 05, 1999 at 10:52:02AM -0300, Alexandre Oliva wrote:
> Richard, it seems that the following patch broke shared library
> construction on alpha-dec-osf4.0:
> 
> Mon Jun 21 20:10:42 1999  Richard Henderson  <rth@cygnus.com>
> 
> 	* collect2.c (main): Log frame table count.
> 	(GCC_OK_SYMBOL) [ECOFF]: Accept stGlobal.
> 	(scan_prog_file) [COFF]: Handle frame tables.

Without this patch, absolutely no EH works, staticly linked
or otherwise.

> FAIL: g++.brendan/nest21.C (test for excess errors)
> /usr/bin/ld:
> /usr/local/tmp/egcs/gcc/libgcc.a(_eh.o): \
> _GLOBAL_$F$__default_terminate: multiply defined

So we need to somehow prevent libgcc symbols from being exported
from the shared library.  I don't know DU well enough to know if
that's possible.


r~

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

On Jul 13, 1999, Richard Henderson <rth@cygnus.com> wrote:

> On Tue, Jul 13, 1999 at 12:50:59AM -0300, Alexandre Oliva wrote:
>> But a *very serious* set of known problems.  The way it is now,
>> libstdc++ on OSF4/alpha is useless for any non-trivial C++ program.
>> :-(

> What you mean is that a _shared_ libstdc++ is useless.

Yup, I had intended to write libstdc++.so

> Our position at this point must be that you must use a static
> libstdc++ on osf for this release.

Well, this means you're just pushing the problem onto the user.  OSF
is smart enough to copy symbols from static libraries into shared
libraries.  However, if more than one shared library gets the same
symbols, you won't be able to link them together.  This means you're
condemning OSF users not only to bloat their executables because of
libstdc++, but also because of almost *any other C++ library*.  I.e.,
if they link the library with g++ -shared, the library will be linked
with libstdc++.  If libstdc++ is static, some symbols will be copied
from it.  Now create another library with the same procedure, and you
won't be able to link them into the same program.

Anyway, if your position is to recommend static libstdc++, I see no
reason to reject my patch, given that it fixes a very serious problem
in a configuration that's broken and not recommended anyway, it's
platform specific and has minimal impact.  The other option is to
change libstdc++/configure.in to completely disable shared library
support on OSF, or at least emit large blinking warnings that it's
broken, which doesn't seem reasonable to me if there's such a trivial
patch that fixes the problem.

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

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Jeffrey A Law]

  In message < ork8s4bhhp.fsf@cupuacu.lsd.dcc.unicamp.br >you write:
  > Anyway, if your position is to recommend static libstdc++, I see no
  > reason to reject my patch, given that it fixes a very serious problem
  > in a configuration that's broken and not recommended anyway, it's
  > platform specific and has minimal impact.  The other option is to
  > change libstdc++/configure.in to completely disable shared library
  > support on OSF, or at least emit large blinking warnings that it's
  > broken, which doesn't seem reasonable to me if there's such a trivial
  > patch that fixes the problem.
Sorry.  This is not going into this release.  First and foremost, the change is
wrong.  Shared libraries need to be self-contained.  Anything else is not
acceptable.  Thus it is not acceptable to simply remove libgcc from a shared
library link line.

In addition to simply being wrong you'll introduce a new and terrible
incompatibility with previous tools because if someone rebuilds a shared
library, it will now be incomplete and there's a good chance it will not
longer work (and thus break any applications which used that library).

This is nearly identical to all the problems that surfaced when some symbols
were made weak in the EH code in egcs-1.1.2.  It was a complete and total
disaster and we do *NOT* want to repeat it.

What we have to do (not for gcc-2.95) is find a way to prevent shared libraries
from re-exporting symbols they get from libgcc.

This change is not going into gcc-2.95.  No way.  Sorry.

I would recommend writing a suitable entry for the FAQ or installation
instructions which discusses the issues and possible workarounds.

jeff

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Philipp Thomas]

On Tue, 06 Jul 1999 23:31:46 -0600, Jeffrey A Law <law@cygnus.com>
wrote:

>This is a long-standing known issue (the need to control which symbols are
>exported from libgcc).

If binutils would work on every platform, I'd propose using symbol
versioning like glibc2 does. That would a) bring us versioned symbols
(not quite so important because libgcc is static) but b) would allow
for easy hiding.

Or is it more of a question of what to hide then of how ?

Philipp

-- 
Linux only became possible because 20 years of OS research was
carefully studied, analyzed, discussed and thrown away.
                                        Ingo Molnar on linux-kernel

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Jeffrey A Law]

  In message <orr9mav362.fsf@cupuacu.lsd.dcc.unicamp.br>you write:
  > >> AFAICT, there are only three ways to prevent this: (i) link with
  > >> `-hidden -lgcc', so that symbols from libgcc are made local to the
  > >> shared library; this is a problem because then we can have multiple
  > >> separate definitions of the same symbols; or (ii) arrange that libgcc
  > >> is shared, so that symbols are not copied, but libstdc++ is noted to
  > >> depend on libgcc; I know there are reasons to prefer not to do it.  So 
  > >> I don't see any way out :-(
  > 
  > > It really is a *(&@#$)(* mess and no matter what you do, you're just
  > > going to trade one set of bugs for another.  Thus my reluctance to
  > > do anything since no solution is clearly better than the others.
  > 
  > Actually, I wrote that before confirming what I had believed from the
  > beginning, which is that DU's ld actually *does* ignore duplicate
  > definitions when they're the same, but it fails to do so in some cases
  > because of a bug.  So I don't think we should care about this problem
  > any more.
I spoke with Jason about this stuff while I was in Sunnyvale a couple weeks 
ago.
He thinks we just have to bite the bullet and go with a shared libgcc.

So we need to start thinking in that direction across all the targets where we
support building shared libraries.

Among other things this means:

	* We will want to move libgcc out of $libsubdir and put it in $libdir

	* We will need to have a version #-ing scheme.  We may (or may not)
	need something like HJ's interface patch for libgcc

	* We need some reasonable way to describe how to build shlibs that
	we can use across gcc, libstdc++, libiberty, etc etc.

I'm sure there's a bunch of other issues we're going to need to tackle, but we
can at least start thinking about them and moving in the right direction.

I stronly doubt we'll fix this for the gcc-2.95 minor releases, but it would
be good to fix it for the next major release.

jeff

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

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:

Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d

[Alexandre Oliva]

On Jul 14, 1999, Jeffrey A Law <law@cygnus.com> wrote:

>> How about linking the entire libgcc.a into libstdc++.so, with `-all
>> -lgcc', so that g++ doesn't explicitly link with -lgcc?  Would that be 
>> reasonable for 2.95.1?

> Ewww.  Actually, this is bad too since all code which uses libstdc++
> will then expect libstdc++ to provide all symbols from libgcc.
> Later if we fix the problem we're going to gratuitiously break lots
> of code that did not get its own copy of any libgcc routines because
> libstdc++ had all of libgcc and exported everything.

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.

FYI, the last patch I posted was indeed incomplete: delete3.C still
complained about some duplicate symbols in libgcc's new.o, _eh.o and
exception.o.  If I come up with a solution, be it
`-Wl,-all,-lgcc,-none' or
`-Wl,-u,__some_symbol,-u,__some_other_symbol,...', may I mention it in
the specific.html web page, along with the possible negative
consequences of it?

>> AFAICT, there are only three ways to prevent this: (i) link with
>> `-hidden -lgcc', so that symbols from libgcc are made local to the
>> shared library; this is a problem because then we can have multiple
>> separate definitions of the same symbols; or (ii) arrange that libgcc
>> is shared, so that symbols are not copied, but libstdc++ is noted to
>> depend on libgcc; I know there are reasons to prefer not to do it.  So 
>> I don't see any way out :-(

> It really is a *(&@#$)(* mess and no matter what you do, you're just
> going to trade one set of bugs for another.  Thus my reluctance to
> do anything since no solution is clearly better than the others.

Actually, I wrote that before confirming what I had believed from the
beginning, which is that DU's ld actually *does* ignore duplicate
definitions when they're the same, but it fails to do so in some cases
because of a bug.  So I don't think we should care about this problem
any more.

>> But then, when it finds the symbols in libgcc.a, it ``remembers''
>> they were already defined in libstdc++.so, and reports them as
>> duplicates.  A linker bug.  :-(

> Then let's report it to dec/compaq/whomever, get it fixed and avoid the
> issues entirely instead of trying to hack around it.

Yup, I'll try to get a small test case, but I don't have any official
contact for bug reporting within dec/compaq/whomever, does anybody?

>> How does this look for 2.95?

> Not for gcc-2.95.  There's way too much risk, too many unknowns, etc etc.

Yup, I see.  It's easy to overlook something when desperately trying
to fix a problem :-)

It's very good to have someone as careful as you leading the project.
Thanks, Jeff! :-)

> *Maybe* for gcc-2.95.1.  *MAYBE*.

When I find a reduced testcase, if it's small enough, I may try to
come up with an autoconf test to detect the bug and enable the
work-around, or simply to disable or just warn about the shared
libstdc++ problem, if you think it's worth it.

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