Re: [PATCH] LD: PROVIDE_HIDDEN export class problem

["Maciej W. Rozycki" <macro at codesourcery dot com>]

Dave,

> > 2. For the hppa64-hp-hpux11.23 and hppa64-linux targets the backend
> >     produces .dynsym and .dynstr sections even in static links.  The former
> >     section is empty and the latter contains a single zero byte, however
> >     the result is they show up in `readelf -s' dumps.  Other dynamic
> >     sections are also produced as is a dynamic segment.
> > 
> >     This is probably a bug in these backends; especially for Linux I fail
> >     to see a reason why the kernel would require any dynamic file
> >     structures in a static executable.  I will appreciate feedback from
> >     HPPA maintainers; meanwhile I have tweaked test patterns to discard
> >     rubbish before static symbol table dumps to avoid failures on these
> >     targets (I'd prefer to remove the tweak though, if that is indeed a
> >     bug).
> This is definitely intentional for HP-UX.  See discussion in this
> thread: <http://sourceware.org/ml/binutils/2002-02/msg00365.html>.
> 
> For Linux, it's probably a bug but it isn't a problem as far as
> I know.

 Thanks for your input.  The new version of the tests I've just posted 
includes some negative tests that ensure that even if a dynamic symbol 
table is present, it does not contain the unwanted symbol.  This makes me 
less nervous about false positives the tests might otherwise score owing 
to the "#..." clause at the beginning, so I think the oddity of hppa64-* 
targets is not going to matter here.

 However I do hope that such "static" executables still run correctly on 
Linux systems that lack `ld.so' altogether -- as from my observation a 
PT_INTERP segment is also included.  I'm leaving it up to you to resolve 
though if you think it's worth doing -- it looks to me it might be.

  Maciej