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 9861C1382C5 for ; Sun, 10 Jan 2021 22:49:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DA20DE0AB0; Sun, 10 Jan 2021 22:49:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 9C042E0A8E for ; Sun, 10 Jan 2021 22:49:51 +0000 (UTC) Subject: Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. To: gentoo-dev@lists.gentoo.org References: <001793010784d3ee41e95f66a051b199010ae056.camel@gentoo.org> From: Joshua Kinard Openpgp: preference=signencrypt Message-ID: Date: Sun, 10 Jan 2021 17:49:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.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: <001793010784d3ee41e95f66a051b199010ae056.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 87247a5a-6ab5-4a95-8f0c-6cdb6e844bf9 X-Archives-Hash: 9998e4a0ccc119daed854076169c4cd1 On 1/10/2021 09:47, Michał Górny wrote: > On Sun, 2021-01-10 at 14:54 +0100, Fabian Groffen wrote: >> On 10-01-2021 14:34:13 +0100, Michał Górny wrote: >>> The vast majority of libtool-based programs use configure script to >>> generate libtool. However, a few non-autoconf packages also use libtool >>> 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? >> >> I would prefer option 2, also because on some systems usr/bin/libtool is >> some entirely different tool than GNU libtool. >> >> I remember this being much more of a problem ~15 years ago, so I wonder >> do we have an easy way of crafting a list of affected packages, such >> that we can see how big the problem actually is nowadays? I'm thinking >> perhaps tinderbox logs or something can reveal /usr/bin/libtool usage >> somehow. > > I think it might be possible to do something akin USE=-native-symlinks > that makes libtool not install /usr/bin/libtool, and see what breaks. > However, I'm not sure if this executable isn't required for some obscure > reason anyway. Second option seems better, and basically just enforces what's been a standard habit anyways (I at least try to manually rebuild libtool when changing gcc major versions, but not so much for minor versions). -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic