Re: fix target/15700

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Mar 16, 2005 at 02:01:46PM -0800, Richard Henderson wrote:
> The alias doesn't make sense though.  Note, for instance, that 
> you'd get a hard error from the Solaris assembler for this.  I
> wish that GAS would do the same thing, but don't really want to
> do the work myself.  ;-)
> 
> I also prefer the glibc approach because it doesn't require that
> we play any games with the preprocessor as with the above.

I agree what libxml2 etc. was using is very ugly and basically abuse
of the alias attribute.

> Assuming that breaking these packages is considered a show-stopper,
> what semantics do you suggest for the above alias?  Do we simply
> defer the alias indefinitely, waiting for the target symbol to be
> defined, and then happily take no action in the case it never does
> get defined?  I'd have thought this would be a source of frustration
> as well -- a typo in the alias string turns it into a silent no-op.

I was thinking more in the direction if what glibc and these packages
want is not common enough GCC could take care of that itself.
Say add a new visibility type (not sure how to call it) for
__attribute__((visibility ())) etc., and GCC would create the internal
hidden alias and redirect all uses to that.  The internal aliases
could be say the symbol name contatenated with say .__hidden or something
(if the target allows dots in symbol names), so that it does not
clash with user's symbols.

Or we could redefine the meaning of internal visibility in GNU ld
from how it behaves ATM (it is the same as hidden I believe, but not
specified how it should work) to this.  But it is probably too late
for that.

	Jakub