Re: elflink.h -Bsymbolic change

["H . J . Lu" <hjl at lucon dot org>]

On Sun, Apr 08, 2001 at 02:24:48PM -0700, Ulrich Drepper wrote:
> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 
> >     if ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT) != 0
> >         && eif->info->shared
> > !       && (eif->info->symbolic
> > ! 	  || ELF_ST_VISIBILITY (h->other) == STV_INTERNAL
> > ! 	  || ELF_ST_VISIBILITY (h->other) == STV_HIDDEN)
> >         && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) != 0)
> >       {
> >         struct elf_backend_data *bed;
> 
> This is definitely more correct.  Although the STV_INTERNAL might have

Agreed. Alan, did you run "make check" on Linux/ia32 with glibc 2.2?
Your change will cause ELF visibility failures :-). I knew it would
be broken by some changes. That is why I added those tests. But the ELF
protected visibility only works with glibc 2.2. Can we fix it please?
Thanks.

> some processor-specific meaning.  But since I'm not aware of any which
> differs from STV_HIDDEN in this respect I think it's fine.

I think it is ok:

   STV_INTERNAL
          The  meaning  of  this  visibility  attribute may be defined by
          processor  supplements  to  further constrain hidden symbols. A
          processor  supplement's  definition should be such that generic
          tools can safely treat internal symbols as hidden.
          An  internal  symbol  contained in a relocatable object must be
          either  removed  or  converted  to  STB_LOCAL  binding  by  the
          link-editor  when  the  relocatable  object  is  included in an
          executable file or shared object.


H.J.