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 C7E503858406 for ; Wed, 17 Nov 2021 10:32:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C7E503858406 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-558-tEA_pZ-LP9Kh0e0JCXggug-1; Wed, 17 Nov 2021 05:31:31 -0500 X-MC-Unique: tEA_pZ-LP9Kh0e0JCXggug-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 605E187D544; Wed, 17 Nov 2021 10:31:30 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8748A60D30; Wed, 17 Nov 2021 10:31:29 +0000 (UTC) From: Florian Weimer To: Yann Droneaud Cc: libc-alpha@sourceware.org Subject: Re: Compatibility .so linker scripts for merged libraries References: <4f1e47f0-e9ae-a2ce-7c12-bd8d4d6adba5@opteya.com> Date: Wed, 17 Nov 2021 11:31:27 +0100 In-Reply-To: <4f1e47f0-e9ae-a2ce-7c12-bd8d4d6adba5@opteya.com> (Yann Droneaud's message of "Tue, 16 Nov 2021 14:27:05 +0100") Message-ID: <87ee7f845c.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.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 17 Nov 2021 10:32:13 -0000 * Yann Droneaud: > Was it considered dangerous to introduce "compatibility" .so link > scripts for the libraries that was merged into libc.so (libpthread,=20 > librt, libdl, etc.) ? > > > > For example: > $ cat librt.so > /* GNU ld script > =C2=A0=C2=A0 Use the static library */ > OUTPUT_FORMAT(elf64-x86-64) > GROUP ( /lib/x86_64-linux-gnu/librt.a ) > > > Because I'm having some bad times fixing issues in a build system that > try to locate now missing .so with gcc -print-file-name=3D then uses the= =20 > paths to the libraries instead of -l name them. Which build system is that? This seems to be rather uncommon. Adding non-loadable .so files tends to break other things. We have seen some breakage as well due to the merging, but they have been clear bugs in the build systems. Like testing whether linking against -lpthread is needed to make pthread_create available, and then using that flag (the need for -lpthread) as an indicator whether threading is available and pthread_create should be used. But the -print-file-name=3D stuff is new to me. Thanks, Florian