From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 088763858012 for ; Mon, 10 Jan 2022 13:01:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 088763858012 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-403-1h4PUsSJOqOPDvdyr4zdZQ-1; Mon, 10 Jan 2022 08:00:47 -0500 X-MC-Unique: 1h4PUsSJOqOPDvdyr4zdZQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 910D91023F53; Mon, 10 Jan 2022 13:00:42 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.102]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B9880105B21E; Mon, 10 Jan 2022 13:00:41 +0000 (UTC) From: Florian Weimer To: Joseph Myers Cc: Subject: Re: Why -static-libgcc? (Or: Do we need a build-time libc.so linker script?) References: <87y25dmc7k.fsf@oldenburg.str.redhat.com> Date: Mon, 10 Jan 2022 14:00:39 +0100 In-Reply-To: (Joseph Myers's message of "Wed, 24 Nov 2021 23:19:29 +0000") Message-ID: <87v8yrycco.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 13:01:14 -0000 * Joseph Myers: > On Wed, 24 Nov 2021, Florian Weimer via Libc-alpha wrote: > >> Why do we use -static-libgcc? Doesn't this invalidate some of our >> tests, because users do not generally build with -static-libgcc? > > There is a principle that (a) building glibc should not require a GCC > built with shared libgcc (to avoid circular dependencies, because building > shared libgcc requires having first built shared libc) and (b) if you > build glibc with a static-only C-only inhibit_libc GCC, the resulting > stripped binaries should be identical to those you get from a longer > alternating sequence of GCC and glibc builds (in particular, the binaries > should be identical to those you get from building with shared libgcc > available) I agree that this is a useful goal. > So building installed shared libraries needs to avoid any dependence on > shared libgcc (unless such dependence is handled in a way not requiring > shared libgcc to be available at build time - note that we know the > libgcc_s SONAME via shlib-versions, so if desired we could insert a > DT_NEEDED for it without using the real library, by building a dummy > shared library to link against or otherwise). I think we could still build without -static-libgcc and check that the installed shared objects do not contain a DT_NEEDED references to libgcc_s. But it will not fix the test linking issue I encountered (libgcc_eh.a references not resolvable against ld.so because of --as-needed and link order). Do we really need to support building the test suite against a static-only GCC build? This is not an urgent issue because direct symbol access to ld.so is incompatible with static dlopen because it the inner namespace binds to the uninitialized copy of ld.so, so things like __tls_get_addr do not work. For some application scenarios, this is probably okay, but for parts of libgcc_s (libgcc_eh.a especially), not so much. Thanks, Florian