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.133.124]) by sourceware.org (Postfix) with ESMTPS id 4841C3857C74 for ; Wed, 24 Nov 2021 22:16:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4841C3857C74 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-124-iRkBxP8KNKGvDa4uiHiG-w-1; Wed, 24 Nov 2021 17:16:18 -0500 X-MC-Unique: iRkBxP8KNKGvDa4uiHiG-w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1B957106B3A3 for ; Wed, 24 Nov 2021 22:16:18 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 73C365DF21 for ; Wed, 24 Nov 2021 22:16:17 +0000 (UTC) From: Florian Weimer To: libc-alpha@sourceware.org Subject: Why -static-libgcc? (Or: Do we need a build-time libc.so linker script?) Date: Wed, 24 Nov 2021 23:16:15 +0100 Message-ID: <87y25dmc7k.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.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.9 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_H2, 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: Wed, 24 Nov 2021 22:16:23 -0000 We have: define build-shlib-helper $(LINK.o) -shared -static-libgcc -Wl,-O1 $(sysdep-LDFLAGS) \ $(if $($(@F)-no-z-defs)$(no-z-defs),,-Wl,-z,defs) $(rtld-LDFLAGS) \ $(extra-B-$(@F:lib%.so=%).so) -B$(csu-objpfx) \ $(extra-B-$(@F:lib%.so=%).so) $(load-map-file) \ -Wl,-soname=lib$(libprefix)$(@F:lib%.so=%).so$($(@F)-version) \ $(LDFLAGS.so) $(LDFLAGS-lib.so) $(LDFLAGS-$(@F:lib%.so=%).so) \ -L$(subst :, -L,$(rpath-link)) -Wl,-rpath-link=$(rpath-link) endef And: define build-module-helper $(LINK.o) -shared -static-libgcc $(sysdep-LDFLAGS) $(rtld-LDFLAGS) \ $(if $($(@F)-no-z-defs)$(no-z-defs),,-Wl,-z,defs) \ -B$(csu-objpfx) $(load-map-file) \ $(LDFLAGS.so) $(LDFLAGS-$(@F:%.so=%).so) \ -L$(subst :, -L,$(rpath-link)) -Wl,-rpath-link=$(rpath-link) endef Why do we use -static-libgcc? Doesn't this invalidate some of our tests, because users do not generally build with -static-libgcc? Background: I'm dealing with an issue caused by a symbol reference from libgcc_eh.a to ld.so. We do not link test modules against a libc.so linker script, instead we use: link-libc-args = -Wl,--start-group \ $(libc-for-link) \ $(common-objpfx)libc_nonshared.a \ -Wl,--as-needed $(elf-objpfx)ld.so -Wl,--no-as-needed \ -Wl,--end-group I believe this is the reason why libgcc_eh.a can't reference ld.so: The initial ld.so gets droped due to --as-needed, and the -lc after libgcc_eh.a does not supply a second copy because it ends up linking against the in-tree libc.so, which just the ELF object. Dropping -static-libgcc seems to make this work. An alternative would be to use a libc.so linker script during the glibc as build (not just after installtion). This should bring back the ld.so reference with -lc after libgcc_eh.a. Thanks, Florian