From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by sourceware.org (Postfix) with ESMTPS id B79AF3858D35 for ; Tue, 16 Nov 2021 13:27:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B79AF3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=opteya.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=opteya.com Received: from [IPV6:2a01:e35:39f2:1220:d07d:1a87:5ecd:281] (unknown [IPv6:2a01:e35:39f2:1220:d07d:1a87:5ecd:281]) by smtp2-g21.free.fr (Postfix) with ESMTPS id 288F32003E0 for ; Tue, 16 Nov 2021 14:27:05 +0100 (CET) Message-ID: <4f1e47f0-e9ae-a2ce-7c12-bd8d4d6adba5@opteya.com> Date: Tue, 16 Nov 2021 14:27:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 To: libc-alpha@sourceware.org Content-Language: fr-FR From: Yann Droneaud Organization: OPTEYA Subject: Compatibility .so linker scripts for merged libraries Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * 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: Tue, 16 Nov 2021 13:27:10 -0000 Hi, Was it considered dangerous to introduce "compatibility" .so link scripts for the libraries that was merged into libc.so (libpthread, librt, libdl, etc.) ? For example: $ cat librt.so /* GNU ld script    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= then uses the paths to the libraries instead of -l name them. Regards. -- Yann Droneaud OPTEYA