RE: Avoiding libgcc_s.so dependency

RE: Avoiding libgcc_s.so dependency

[lrtaylor]

You can tell GCC to statically link in libgcc with the -static-libgcc
option.  However, it sounds like your ssl library was dynamically linked
with it, so, so long as you're linking to the libcrypto.so instead of
libcrypto.a, you're going to get it's dependencies as well.  The only
way to can avoid getting its dependencies as well is to either link to
the static version, or to relink (i.e., rebuild) libcrypto.so so that it
is statically linked to its dependencies.

The linker always prefers .so files of .a files if it has a choice.  You
can tell it to only link to static libraries something like this:

gcc <blah blah blah> -static-libgcc -Wl,-B,static -lfoo -lbar
-Wl,-B,dynamic

That should work, if you're using the Solaris linker.  What will happen
is that it will link to libfoo.a and libbar.a.  If it can't find either
of them (for example, if libfoo.so exists, but not libfoo.a), it will
produce an error.  The last argument tells the linker to prefer
dynamical linking again.  That way, you will get shared versions of the
system libraries.

Does that make sense?

Thanks,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Stian Oksavik
Sent: Sunday, August 01, 2004 6:13 AM
To: gcc-help@gcc.gnu.org
Subject: Avoiding libgcc_s.so dependency

Howdy all,

I'm struggling with libgcc_s.so.1. It seems that pretty much any
non-trivial program I compile ends up depending on libgcc_s.so.1.
Basically, this means that I can't distribute software without also
distributing this library, which is problematic for any number of
reasons.

I've been told to just build static binaries to avoid this problem,
but this is not an option on Solaris as Sun does not include all the
libraries needed to build static libraries of most software. My goal
is to be able to build binaries that avoid dependencies on any
third-party libraries, and only depends on Sun's bundled libraries.

The current project -- and problem -- is with OpenSSH 3.8.1p1 under
Solaris 9/sparc. OpenSSH picks up libcrypto.so.1 from OpenSSL (even
though libcrypto.a also exists), and that in turn forces libgcc_s.so.1
into the equation -- no matter what combination of gcc and ld flags I
try to keep this from happening.

So, two questions:

a) What is the purpose of libgcc_s.so.1, and does this purpose
outweigh the inconvenience this library causes? (Including one machine
we could no longer log into because removing the SMCgcc package from
it disabled sshd?)

b) Is there ANY way to get rid of this dependency without building a
fully static binary?


Thanks,

-Stian

Avoiding libgcc_s.so dependency

[Stian Oksavik]

Howdy all,

I'm struggling with libgcc_s.so.1. It seems that pretty much any
non-trivial program I compile ends up depending on libgcc_s.so.1.
Basically, this means that I can't distribute software without also
distributing this library, which is problematic for any number of
reasons.

I've been told to just build static binaries to avoid this problem,
but this is not an option on Solaris as Sun does not include all the
libraries needed to build static libraries of most software. My goal
is to be able to build binaries that avoid dependencies on any
third-party libraries, and only depends on Sun's bundled libraries.

The current project -- and problem -- is with OpenSSH 3.8.1p1 under
Solaris 9/sparc. OpenSSH picks up libcrypto.so.1 from OpenSSL (even
though libcrypto.a also exists), and that in turn forces libgcc_s.so.1
into the equation -- no matter what combination of gcc and ld flags I
try to keep this from happening.

So, two questions:

a) What is the purpose of libgcc_s.so.1, and does this purpose
outweigh the inconvenience this library causes? (Including one machine
we could no longer log into because removing the SMCgcc package from
it disabled sshd?)

b) Is there ANY way to get rid of this dependency without building a
fully static binary?


Thanks,

-Stian