.symver

Tom Kacvinsky tkacvins@gmail.com
Tue Jan 19 14:26:47 GMT 2021


I have made more progress on this and it looks to me, for the code I
am working with,
that .symver overrides a symbol being marked as weak.  So

.weak pthread_key_create
.symver pthread_key_create, pthread_key_create@GLIBC_2.2.5

Removes the symbol as being marked weak and wants to resolve against
pthread_key_create@GLIBC_2.2.5.
That's what I've observed anyway.  Sample code is

#include <stdio.h>
#include <pthread.h>

extern int pthread_key_create (pthread_key_t *, void (*) (void *))
__attribute__ ((weak));
__asm__(".symver pthread_key_create,pthread_key_create@GLIBC_2.2.5");

void destructor(void* arg) { return; }

void thread_func() {
  pthread_key_t key;

  pthread_key_create(&key, destructor);
}

 gcc -fPIC -o thread.so -save-temps -shared thread.c
ld: error: symbol pthread_key_create has undefined version GLIBC_2.2.5
collect2: error: ld returned 1 exit status

Using binutils 2.34, but also happens with binutils 2.35.1

Tom


On Wed, Jan 13, 2021 at 6:23 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Tom,
>
> > I am in the process of building some software were I inject .symver
> > instructions into the assembly generated by GCC, then assembly it.  What I
> > found is .symver actually inserts the symbol that is
> > referred to in the instruction into the object code, which causes problems
> > later down the road.
>
> You could make the .symver directive conditional upon the symbol already
> being defined by:
>
>    .ifdef SYM
>    .symver SYM, NAME2
>    .endif
>
> > Is there a way to tell the linker to
> > not use those symbols if they are
> > not used  in the generated object code?
>
> Well if the symbol is in an archive library (eg libfoo.a) then it will only
> be pulled into the link if it is needed, or other symbols in object file
> containing it are needed.
>
> You might also be able to use the visibility argument to .symver to solve
> the problem.  If you make the symbols internal for example then they should
> not trigger the loading of other libraries.
>
> Cheers
>    Nick
>


More information about the Binutils mailing list