Copy relocations against versioned symbols with aliases without a default version

[Florian Weimer <fweimer at redhat dot com>]

I'm trying to clean up the timezone code in glibc.  Historically, we 
export both tzname and __tzname, and the symbols are aliased:

   271: 0000000000399380    16 OBJECT  GLOBAL DEFAULT   33 
__tzname@@GLIBC_2.2.5
   589: 0000000000399380    16 OBJECT  WEAK   DEFAULT   33 
tzname@@GLIBC_2.2.5

__tzname was exported more or less by accident, so I want to turn it 
into a compat symbol, resulting in:

   271: 0000000000399380    16 OBJECT  GLOBAL DEFAULT   33 
__tzname@GLIBC_2.2.5
   589: 0000000000399380    16 OBJECT  WEAK   DEFAULT   33 
tzname@@GLIBC_2.2.5

When linking an object file with an R_X86_64_32S relocation against tzname

  bb:   4d 8b 64 dd 00          mov    0x0(%r13,%rbx,8),%r12
  c0:   48 8b 2c dd 00 00 00    mov    0x0(,%rbx,8),%rbp
  c7:   00
                        c4: R_X86_64_32S        tzname
  c8:   4c 89 e6                mov    %r12,%rsi

to this variant, I get this error:

/usr/bin/ld: …/tst-timezone.o(.text+0xc4): unresolvable R_X86_64_32S 
relocation against symbol `tzname@@GLIBC_2.2.5'

This is really unexpected.  It seems that something causes the hidden 
bit to be set on the compat symbol version for __tzname.  I assume ld 
treats this as an indication that a hidden alias symbol exists, so that 
it cannot create a copy relocation without breaking the alias.

This is really fishy.  The hidden bit is documented as “If the highest 
bit (bit 15) is set this is a hidden symbol which cannot be referenced 
from outside the object.” in 
<https://www.akkadia.org/drepper/symbol-versioning>, but this is not 
what is implemented because references to these supposedly-hidden 
symbols work just fine if you specify an explicit symbol version, both 
at static link time and at run time (which is not something we can 
change in the dynamic linker because we have many existing binaries 
which use hidden symbol versions for supposedly-exported non-default 
compat symbols).  So there is no real reason why the static linker has 
to refuse to create a copy relocation in such a cases.

Comments?

Thanks,
Florian