From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47104 invoked by alias); 13 Mar 2019 09:36:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 47089 invoked by uid 89); 13 Mar 2019 09:36:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:799 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Mar 2019 09:36:58 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A1CF30A7C9E for ; Wed, 13 Mar 2019 09:36:57 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-117-152.ams2.redhat.com [10.36.117.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 99371601A5 for ; Wed, 13 Mar 2019 09:36:56 +0000 (UTC) From: Florian Weimer To: gcc@gcc.gnu.org Subject: Linking against libgcc.a on GNU/Linux Date: Wed, 13 Mar 2019 09:36:00 -0000 Message-ID: <87r2bbkte1.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00106.txt.bz2 Would it be possible to turn libgcc_s.so into a linker script that links against libgcc.a and libgcc_s.so.1, and teach g++ not to link against libgcc.a explicitly anymore? I'm suggesting this because libtool uses -nostdlib when linking shared objects in C++ mode, and does not link against -lgcc, only -lgcc_s. This causes subtle problems if GCC generates code that actually needs libgcc.a, particularly if the main program uses the same symbols and gets the hidden definitions from libgcc.a. As far as I can tell, previous attempts to dissuade libtool from using -nostdlib have failed. It is also difficult to change libtool as it is deployed in package sources. It seems to me that the GCC workaround could be rolled out quite seamlessly. Thanks, Florian