From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by sourceware.org (Postfix) with ESMTPS id A33693858402 for ; Wed, 17 Nov 2021 21:33:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A33693858402 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:2091:8213:eaf2:edb0] (unknown [IPv6:2a01:e35:39f2:1220:2091:8213:eaf2:edb0]) by smtp4-g21.free.fr (Postfix) with ESMTPS id 90FDC19F5A3; Wed, 17 Nov 2021 22:32:56 +0100 (CET) Message-ID: <8fd56fb7-4379-77c7-43f3-76950e77390e@opteya.com> Date: Wed, 17 Nov 2021 22:32:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: Compatibility .so linker scripts for merged libraries Content-Language: fr-FR To: Florian Weimer Cc: libc-alpha@sourceware.org References: <4f1e47f0-e9ae-a2ce-7c12-bd8d4d6adba5@opteya.com> <87ee7f845c.fsf@oldenburg.str.redhat.com> From: Yann Droneaud Organization: OPTEYA In-Reply-To: <87ee7f845c.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, 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-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 21:33:03 -0000 Hi, Le 17/11/2021 à 11:31, Florian Weimer a écrit : > * Yann Droneaud: > >> 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. > Which build system is that? This seems to be rather uncommon. It's surely is uncommon, and need to be fixed. Adding fake .so would have, in my mind, buying some time to upgrade. But this is pointless if no other projects are having the same issue. > Adding non-loadable .so files tends to break other things. I was afraid you said that, but I expected it :) With is piece of information, I have enough motivation to request a fix on the build system the project I work for is using. > 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= stuff is new to me. Regards. -- Yann Droneaud OPTEYA