shared library name resolution
Rex Dieter
rdieter at math.unl.edu
Fri Jun 16 12:52:57 UTC 2006
Mike - EMAIL IGNORED wrote:
> On Fedora Core 4, I have some C++ code developed
> that I keep in a library. Until recently, I used
> ar to generate a libXXX.a . Now I have changed to:
>
> TARGET = libXXX.so
> CPPFLAGS = -fPIC -DPIC -O3 -I.
>
> $(TARGET): $(OBJ)
> gcc -shared $(CPPFLAGS) -o $(TARGET) $(OBJ)
>
> to create libXXX.so , and I noticed that some
> executables dropped in size by about a factor
> of 10. Good.
>
> Now some of the code in my library depends on
> the realtime and openssl libraries so when
> utilizing these, I have always used:
>
> -l rt -l ssl
>
> in my link lines. But for code that did not depend
> on these capabilities, the corresponding -l were
> not required.
>
> Now, on the contrary, find that these -l designations
> are required WHETHER OR NOT these capabilities are
> needed in the application. Otherwise I get unresolved
> names.
>
> Is this to be expected with shared libraries? Is
> there something I could do to my shared library to
> prevent it?
Avoid unresolved symbols in your shared library. Instead of
linking -lrt -lssl in your apps, add -lrt -lssl when creating the library,
ie, instead of
gcc -shared $(CPPFLAGS) -o $(TARGET) $(OBJ)
do
gcc -shared $(CPPFLAGS) -o $(TARGET) $(OBJ) -lrt -lssl
-- Rex
More information about the fedora-list
mailing list