Is there a gcc flag to skip resolution of symbols by the compile-time linker when building a shared library (that depends on other shared libraries)? For some reason my toolchain is giving undefined reference
errors when I try to build shared library C that depends on B.so and A.so, even though the dependencies are specified and exist. I heard there existed a gcc flag to delay the dependency resolution to runtime.
views:
132answers:
1
+1
A:
I think you're looking for --allow-shlib-undefined
. From the ld
man page:
--allow-shlib-undefined
--no-allow-shlib-undefined
Allows (the default) or disallows undefined symbols in shared libraries.
This switch is similar to --no-undefined except that it determines the
behaviour when the undefined symbols are in a shared library rather than
a regular object file. It does not affect how undefined symbols in regular
object files are handled.
The reason that --allow-shlib-undefined is the default is that the shared
library being specified at link time may not be the same as the one that
is available at load time, so the symbols might actually be resolvable at
load time. Plus there are some systems, (eg BeOS) where undefined symbols
in shared libraries is normal. (The kernel patches them at load time to
select which function is most appropriate for the current architecture.
This is used for example to dynamically select an appropriate memset
function). Apparently it is also normal for HPPA shared libraries to have
undefined symbols.
Allowing undefined symbols is the default, though, so I'm guessing your problem is actually something different.
tgamblin
2010-02-26 00:43:59