From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D8AF71382C5 for ; Mon, 11 Jan 2021 08:53:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51603E0AA3; Mon, 11 Jan 2021 08:52:57 +0000 (UTC) Received: from bagheera.iewc.co.za (bagheera.iewc.co.za [IPv6:2c0f:f720:0:3:be30:5bff:feec:6f99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1B2CAE0A7C for ; Mon, 11 Jan 2021 08:52:56 +0000 (UTC) Received: from [165.16.203.117] (helo=tauri.local.uls.co.za) by bagheera.iewc.co.za with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kyswV-0001Ef-4m; Mon, 11 Jan 2021 10:52:51 +0200 Received: from [192.168.42.205] by tauri.local.uls.co.za with esmtp (Exim 4.93.0.4) (envelope-from ) id 1kyswP-0007cd-5q; Mon, 11 Jan 2021 10:52:45 +0200 To: gentoo-dev@lists.gentoo.org, =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= References: From: Jaco Kroon Organization: Ultimate Linux Solutions (Pty) Ltd Subject: Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. Message-ID: <876b9e4e-b86d-f433-2e0d-f69fa0d6ab5a@uls.co.za> Date: Mon, 11 Jan 2021 10:52:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB X-Spam-report: Relay access (bagheera.iewc.co.za). X-Archives-Salt: a79d72c9-b9a9-415c-9259-d70dabe07c61 X-Archives-Hash: 1a303eb67bebbd7829246e3a530e68ca Hi Micha=C5=82, On 2021/01/10 15:34, Micha=C5=82 G=C3=B3rny wrote: > Hi, > > The vast majority of libtool-based programs use configure script to > generate libtool. However, a few non-autoconf packages also use libtoo= l > by calling system-installed /usr/bin/libtool. The problem is that this= > libtool hardcodes the values of CC/CXX at its' build time, so unless it= > is rebuilt frequently, packages end up using the stale values. > The problem is known since 2005 [1] and hasn't been resolved yet. > > I can think of two ways of solving it: > > 1. We could patch system-installed libtool to respect environment > variables such as CC, CXX, etc. This will probably require carrying > a (possibly non-trivial) patch forever. On the bright side, libtool is= > not exactly a package seeing frequent releases. I mean, the current > version is from 2015. > > 2. We could regenerate libtool and force local instance of libtool > in the packages needing it. The main advantage of this is that it's > a no-brainer. I could make a quick eclass that does configure a local > instance and prepends it into PATH. > > WDYT? 3.=C2=A0 Have it always use some fixed compiler somewhere (ie, compile it= with CC=3D/usr/bin/cc-libtool-wrapper CXX=3D/usr/bin/cxx-libtool-wrapper which quite literally is just scripts that does): exec "${CC}" "$@" and exec "${CXX}" "$@" (with some added logic that if those variables points to itself it needs to do a bit of extra work, or use "${LIBTOOL_CC:-${CC}}" style and compile libtool with LIBTOOL_CC=3D${CC} CC=3D/usr/bin/cc-libtool-wrapper = =2E.. I'd still add logic to detect the infinite recursion of CC=3D$0 though ..= =2E). Would be happy to supply a suitable script if you're interested that you can then just symlink the variants to (libtool-tool-wrapper-{cc,cxx,ld,ar,...}) Kind Regards, Jaco