From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27601 invoked by alias); 2 Aug 2004 16:32:56 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 27582 invoked from network); 2 Aug 2004 16:32:54 -0000 Received: from unknown (HELO masquerade.micron.com) (137.201.242.130) by sourceware.org with SMTP; 2 Aug 2004 16:32:54 -0000 Received: from mail-srv2.micron.com (localhost [127.0.0.1]) by masquerade.micron.com (8.12.9/8.12.2) with ESMTP id i72GX39c028086 for ; Mon, 2 Aug 2004 10:33:03 -0600 (MDT) Received: from ntxboimbx07.micron.com (ntxboimbx07.micron.com [137.201.80.94]) by mail-srv2.micron.com (8.12.9/8.12.2) with ESMTP id i72GX1up028065; Mon, 2 Aug 2004 10:33:02 -0600 (MDT) From: lrtaylor@micron.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Avoiding libgcc_s.so dependency Date: Mon, 02 Aug 2004 16:32:00 -0000 Message-ID: <363801FFD7B74240A329CEC3F7FE4CC40215DB95@ntxboimbx07.micron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: To: , X-Scanned-By: MIMEDefang 2.37 X-SW-Source: 2004-08/txt/msg00007.txt.bz2 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 -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