3

I need to compile a module that is statically linked to lua library (liblua.a) and dynamically linked to dl library (libdl.so).

I've compiled the C source file (generic_loader.c) linking it to dl library:

$ gcc -g generic_loader.c -shared -fpic -ldl -o _loader.o

No errors were shown as I can see the linked libraries and symbol resolution:

$ ldd _loader.o
_loader.o:
linux-vdso.so.1 =>  (0x00007fff231fe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7397949000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7397582000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7397d6e000)

$ nm _loader.o
_loader.o:
0000000000201078 B __bss_start
0000000000201078 b completed.6972
                 w __cxa_finalize@@GLIBC_2.2.5
00000000000008d0 t deregister_tm_clones
                 U dlerror@@GLIBC_2.2.5
                 U dlopen@@GLIBC_2.2.5
                 U dlsym@@GLIBC_2.2.5
0000000000000940 t __do_global_dtors_aux
0000000000200df0 t __do_global_dtors_aux_fini_array_entry
0000000000201070 d __dso_handle
0000000000200e00 d _DYNAMIC
0000000000201078 D _edata
0000000000201080 B _end
0000000000000aec T _fini
0000000000000980 t frame_dummy
0000000000200de8 t __frame_dummy_init_array_entry
0000000000000ba8 r __FRAME_END__
0000000000201000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
00000000000007e8 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
0000000000200df8 d __JCR_END__
0000000000200df8 d __JCR_LIST__
                 w _Jv_RegisterClasses
00000000000009b5 T load_as_global
0000000000000aab T luaopen_genericloader
                 U lua_pushboolean
                 U lua_pushcclosure
                 U lua_pushnil
                 U lua_pushstring
                 U lua_setfield
                 U lua_tolstring
0000000000000900 t register_tm_clones
0000000000201078 d __TMC_END__

The unresolved symbols belongs to lua library and should be handled in the next step, so I guess there is no problem with that binary.

So I compiled the resulting binary _loader.so in order to statically link it to lib lua:

$ gcc -g -shared -fpic _loader.o /usr/local/lib/liblua.a -o genericloader.so

Again, no errors where shown. But when I list the symbols, all dl and lua symbols are missing, as well as load_as_global and luaopen_genericloader, both functions defined in generic_loader.c:

$ldd genericloader.so 
genericloader.so:
linux-vdso.so.1 =>  (0x00007fff7cdfe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f360ad0d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f360b2f4000)

$ nm genericloader.so 

genericloader.so:
0000000000201030 B __bss_start
0000000000201030 b completed.6972
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000000530 t deregister_tm_clones
00000000000005a0 t __do_global_dtors_aux
0000000000200e08 t __do_global_dtors_aux_fini_array_entry
0000000000201028 d __dso_handle
0000000000200e18 d _DYNAMIC
0000000000201030 D _edata
0000000000201038 B _end
0000000000000618 T _fini
00000000000005e0 t frame_dummy
0000000000200e00 t __frame_dummy_init_array_entry
0000000000000628 r __FRAME_END__
0000000000201000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
00000000000004e0 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
0000000000200e10 d __JCR_END__
0000000000200e10 d __JCR_LIST__
                 w _Jv_RegisterClasses
0000000000000560 t register_tm_clones
0000000000201030 d __TMC_END__

Am I missing something, a step in compilation or perhaps an option to gcc?

Thanks in advance.

ericariello
  • 111
  • 1
  • 11
  • 1
    Your `_loader.o` file is not a regular object file but a "shared object" (so) file. Drop the `-shared` and `-ldl` from the first compiler incantation and add `-c` to get a normal object file. – siffiejoe Feb 05 '15 at 23:08
  • Following you suggestion, I found an error running the second compilation: gcc -g -shared -fpic _loader.o /usr/local/lib/liblua.a -o genericloader.so -ldl /usr/bin/ld: /usr/local/lib/liblua.a(lapi.o): relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/liblua.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status – ericariello Feb 06 '15 at 12:12
  • That's because the object files in the static library were compiled without the `-fpic` (or `-fPIC`) flag. – siffiejoe Feb 09 '15 at 11:01

1 Answers1

0

To mix dynamic and static linking you may need to use -Wl,-Bstatic and -Wl,-Bdynamic options as described in this SO answer.

Community
  • 1
  • 1
Paul Kulchenko
  • 25,884
  • 3
  • 38
  • 56
  • Tried gcc -g -shared -fpic generic_loader.c -Wl,-Bstatic -llua5.1 -Wl,-Bdynamic -ldl -o genericloader.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/liblua5.1.a(lapi.o): relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/liblua5.1.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status – ericariello Feb 06 '15 at 12:36
  • This means you should add -fPIC to your liblua compilation. – llogiq May 26 '15 at 12:33