shared library name resolution

[Michael D. Berger]

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?

Thanks for your help.
Mike.

[Rex Dieter]

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

[Ulrich Drepper]

Rex Dieter wrote:
> 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

Or use

gcc -shared $(CPPFLAGS) -o $(TARGET) $(OBJ) -Wl,--as-needed -lrt -lssl
-Wl,--no-as-needed

(one long line).

Firefox problem

[Paul Erickson]

Last night during a system update, new Firefox files were installed. Now 
when I try to email a link of page
from within Firefox it hangs up. The new thunderbird seems to be working 
fine.

Anyone else notice this?

cheers, Paul

[Michael D. Berger]

On Fri, 16 Jun 2006 07:26:37 -0700, Ulrich Drepper wrote:
> Rex Dieter wrote:
> > 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
>
> Or use
>
> gcc -shared $(CPPFLAGS) -o $(TARGET) $(OBJ) -Wl,--as-needed -lrt -lssl
> -Wl,--no-as-needed
>
> (one long line).
>
> -- 
> Ulrich Drepper Red Hat, Inc. 444 Castro St Mountain View, CA

The first suggestion works, but the second does not:

LIBS = -Wl,--as-needed -lrt -lssl -Wl,--no-as-needed

$(TARGET): $(OBJS)
      gcc -shared $(CPPFLAGS) -o $(TARGET) $(OBJS) $(LIBS)

Wherein do I err?
Thanks,
Mike.