 |
lua-l archive |
|
|
||
|
Reuben Thomas wrote:
I've just come across an oddity in making shared libs with gcc which AFAICS amounts to a bug in the default Lua Makefile. If I use ldd on a dynamic library built with the default Makefile it says: statically linked This seems to be caused by the fact that the default Makefile uses ld as the linker. It should use gcc, which gives the expected result. In fact, as someone pointed out earlier, it should really use gcc $(MYCFLAGS) (or $(CC) $(MYCFLAGS), but given it's already Linux-gcc-specific there's little point), so that if you've added -fPIC, that gets used with the linker, as advised in the gcc manpage. Maybe this could go into the "real" 5.0.1?
But when linked with ld, the library *is* statically linked. That is, it does not call for any other libraries to be loaded when it is, and does not mention where to get its external symbols.
When built with gcc -shared, it is linked with (at least) -lc, building in a dependency on libc.so.
The right thing to do when building shared libraries is to include appropriate -lfoo dependencies such that as many dependencies as possible are satisfied at link time. It's convenient to build C-based libraries with gcc, as that gets the dependencies on libc and libgcc implicitly. But it's also good to mark the other dependencies. For example liblualib.so should be linked with -llua to find those dependencies.
There are some systems where this is necessary---I think some versions of Solaris required libraries to have no unresolved external dependencies. I know this is true for the snow ABI on mipsel-linux, where unresolved symbols are not possible in shared objects. Mentioning all your dependent libraries when building shared objects is good practice in general, as it plays nicely with things like symbol versioning, and can get the runtime linker to do the distasteful job of tracing all library dependencies for you.
Jay