1
votes

I have a problem that missing symbols when link static libraries and .o files to a shared libray. I have checked the symbol table of static libray, the functions i needed list in the table normally, like this:

...
00000000 g     F .text  000000b0 av_int2dbl
...
000000b0 g     F .text  00000060 av_int2flt

but when i generate shared library, av_int2dbl and av_int2flt and some else functions missed(they all list in the static symtable normally), I used a stupid method to resolve this problem, by making a dummy function in .o file, and reference to functions missed form the dummy function, the DYNAMIC SYMBOL TABLE of shared library add some functions that missed before, but strange thing is av_int2dbl and av_int2flt missed as before.

Could anybody tell me, what's the principle to remove symbols when generate shared library?

If ld will remove all unreferfenced symbol, why functions defined in .o files (these funcs are not be referenced from other location) existed in shared library still? Why av_int2dbl and av_int2flt are invoked explicitly in dummy func, while disassembly loss the these two funcs?

Below is dummy function defined in .o file:

int my_dummy_funcs(void)
{   
     av_rdft_init(0x01,0x1);
     av_rdft_calc(NULL, NULL);
     av_rdft_end(NULL);

     av_int2dbl(1);
     av_int2flt(1);

     av_resample(NULL,NULL,NULL,NULL,0,0,0);
     av_resample_close(NULL);
     av_resample_init(0,0,0,0,0,1.0);

     return 0;

}

disassemble the dummy function as follow:

0008951c <my_dummy_funcs>:
8951c:  e3a00001    mov r0, #1
89520:  e92d40d0    push    {r4, r6, r7, lr}
89524:  e1a01000    mov r1, r0
89528:  e3a04000    mov r4, #0
8952c:  e24dd010    sub sp, sp, #16
89530:  eb03a21e    bl  171db0 <av_rdft_init>
89534:  e1a01004    mov r1, r4
89538:  e1a00004    mov r0, r4
8953c:  e3a06000    mov r6, #0
89540:  eb03a22f    bl  171e04 <av_rdft_calc>
89544:  e1a00004    mov r0, r4
89548:  eb03a231    bl  171e14 <av_rdft_end>
8954c:  e1a01004    mov r1, r4
89550:  e1a02004    mov r2, r4
89554:  e1a03004    mov r3, r4
89558:  e1a00004    mov r0, r4
8955c:  e58d4000    str r4, [sp]
89560:  e58d4004    str r4, [sp, #4]
89564:  e3a07000    mov r7, #0
89568:  e58d4008    str r4, [sp, #8]
8956c:  eb0e4a62    bl  41befc <av_resample>
89570:  e1a00004    mov r0, r4
89574:  e3437ff0    movt    r7, #16368  ; 0x3ff0
89578:  eb0e4a4a    bl  41bea8 <av_resample_close>
8957c:  e1a00004    mov r0, r4
89580:  e1a01004    mov r1, r4
89584:  e1a02004    mov r2, r4
89588:  e1a03004    mov r3, r4
8958c:  e58d4000    str r4, [sp]
89590:  e1cd60f8    strd    r6, [sp, #8]
89594:  eb0e495f    bl  41bb18 <av_resample_init>
89598:  e1a00004    mov r0, r4
8959c:  e28dd010    add sp, sp, #16
895a0:  e8bd80d0    pop {r4, r6, r7, pc}
1
Perhaps just compile with -ffunction-sections -Wl,--gc-sections?user529758
no,but i found these declaration in a header file :attribute_deprecated double av_int2dbl(int64_t v) av_const; attribute_deprecated float av_int2flt(int32_t v) av_const; but this shouldn't cause symbol loss.fla888

1 Answers

0
votes

but when i generate shared library, av_int2dbl and av_int2flt and some else functions missed

The most likely reason: they are marked as HIDDEN in the regular symbol table, and that tells the linker to not export them in the dynamic symbol table.

You can verify this hypothesis by running

readelf -s libfoo.a | grep av_int2dbl

(and learn to use readelf instead of objdump on ELF platforms).