From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28816 invoked by alias); 20 Feb 2003 16:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 28792 invoked by uid 71); 20 Feb 2003 16:36:00 -0000 Resent-Date: 20 Feb 2003 16:36:00 -0000 Resent-Message-ID: <20030220163600.28790.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, stew@tenbox.com Received: (qmail 25753 invoked by uid 48); 20 Feb 2003 16:30:56 -0000 Message-Id: <20030220163056.25752.qmail@sources.redhat.com> Date: Thu, 20 Feb 2003 16:36:00 -0000 From: stew@tenbox.com Reply-To: stew@tenbox.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: libstdc++/9776: -static-libgcc does not produce a static link to libstdc++, instead always dynamic X-SW-Source: 2003-02/txt/msg00996.txt.bz2 List-Id: >Number: 9776 >Category: libstdc++ >Synopsis: -static-libgcc does not produce a static link to libstdc++, instead always dynamic >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Feb 20 16:36:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Stewart Loving-Gibbard (stew@tenbox.com) >Release: unknown-1.0 >Organization: >Environment: Mandrake 9.0 & Solaris 2.7/2.8, GCC 3.2 >Description: -static-libgcc does not produce a static link to libstdc++; see attached file. >How-To-Repeat: See attached file >Fix: See attached file >Release-Note: >Audit-Trail: >Unformatted: ----gnatsweb-attachment---- Content-Type: text/plain; name="LinuxBugReportGCC.txt" Content-Disposition: inline; filename="LinuxBugReportGCC.txt" I believe the -static-libgcc option does not work properly under GCC 3.2. It always produces a *dynamic* link to /usr/lib/libstdc++.so.5, instead of /usr/lib/libstdc++.a. I'll demonstrate: GCC 3.2: [stew@oppenheimer demostdlib]$ g++ -v Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) libstdc++.a is available: [stew@oppenheimer Linux]$ ls -alg /usr/lib/libstdc++.a lrwxrwxrwx 1 root 56 Feb 18 16:54 /usr/lib/libstdc++.a -> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/libstdc++.a But I always get a dynamic link: [stew@oppenheimer demostdlib]$ cat main.cpp #include #include using namespace std; int main() { const string thisProgram = "This program"; cout << thisProgram << " invokes the standard library!" << endl; return 0; } [stew@oppenheimer demostdlib]$ g++ main.cpp -static-libgcc [stew@oppenheimer demostdlib]$ ./a.out This program invokes the standard library! [stew@oppenheimer demostdlib]$ ldd ./a.out libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40020000) libm.so.6 => /lib/i686/libm.so.6 (0x400e4000) libc.so.6 => /lib/i686/libc.so.6 (0x40107000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40227000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) The example was run on Linux, but I've had the same problem with Solaris. The only way I've found to get a proper static link on /usr/lib/libstdc++.a is to catch the collect2 command (g++ main.cpp -static-libgcc -v), then modify the -lstdc++ to /usr/lib/libstdc++.a. Figuring out how to do this took many confusing hours. I worry that maybe I am confused about what -static-libgcc does; maybe it is not supposed to make the link to libstdc++ static. If not, then I would suggest that such an option is very needed - it is not often reasonable that the user have the precise same version of the C++ runtime library as you. Thank you. I hope I was clear. If not, please write. Stewart Loving-Gibbard stew@tenbox.com