| 1 |
On 1/10/2021 09:47, Michał Górny wrote: |
| 2 |
> On Sun, 2021-01-10 at 14:54 +0100, Fabian Groffen wrote: |
| 3 |
>> On 10-01-2021 14:34:13 +0100, Michał Górny wrote: |
| 4 |
>>> The vast majority of libtool-based programs use configure script to |
| 5 |
>>> generate libtool. However, a few non-autoconf packages also use libtool |
| 6 |
>>> by calling system-installed /usr/bin/libtool. The problem is that this |
| 7 |
>>> libtool hardcodes the values of CC/CXX at its' build time, so unless it |
| 8 |
>>> is rebuilt frequently, packages end up using the stale values. |
| 9 |
>>> The problem is known since 2005 [1] and hasn't been resolved yet. |
| 10 |
>>> |
| 11 |
>>> I can think of two ways of solving it: |
| 12 |
>>> |
| 13 |
>>> 1. We could patch system-installed libtool to respect environment |
| 14 |
>>> variables such as CC, CXX, etc. This will probably require carrying |
| 15 |
>>> a (possibly non-trivial) patch forever. On the bright side, libtool is |
| 16 |
>>> not exactly a package seeing frequent releases. I mean, the current |
| 17 |
>>> version is from 2015. |
| 18 |
>>> |
| 19 |
>>> 2. We could regenerate libtool and force local instance of libtool |
| 20 |
>>> in the packages needing it. The main advantage of this is that it's |
| 21 |
>>> a no-brainer. I could make a quick eclass that does configure a local |
| 22 |
>>> instance and prepends it into PATH. |
| 23 |
>>> |
| 24 |
>>> WDYT? |
| 25 |
>> |
| 26 |
>> I would prefer option 2, also because on some systems usr/bin/libtool is |
| 27 |
>> some entirely different tool than GNU libtool. |
| 28 |
>> |
| 29 |
>> I remember this being much more of a problem ~15 years ago, so I wonder |
| 30 |
>> do we have an easy way of crafting a list of affected packages, such |
| 31 |
>> that we can see how big the problem actually is nowadays? I'm thinking |
| 32 |
>> perhaps tinderbox logs or something can reveal /usr/bin/libtool usage |
| 33 |
>> somehow. |
| 34 |
> |
| 35 |
> I think it might be possible to do something akin USE=-native-symlinks |
| 36 |
> that makes libtool not install /usr/bin/libtool, and see what breaks. |
| 37 |
> However, I'm not sure if this executable isn't required for some obscure |
| 38 |
> reason anyway. |
| 39 |
|
| 40 |
Second option seems better, and basically just enforces what's been a |
| 41 |
standard habit anyways (I at least try to manually rebuild libtool when |
| 42 |
changing gcc major versions, but not so much for minor versions). |
| 43 |
|
| 44 |
-- |
| 45 |
Joshua Kinard |
| 46 |
Gentoo/MIPS |
| 47 |
kumba@g.o |
| 48 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
| 49 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
| 50 |
|
| 51 |
"The past tempts us, the present confuses us, the future frightens us. And |
| 52 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 53 |
|
| 54 |
--Emperor Turhan, Centauri Republic |
Archives