.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