Mailing List Archive: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

[RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

Jan 10, 2021, 5:34 AM

Post #1 of 7 (147 views)

Hi,

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?

[1] https://bugs.gentoo.org/88596

--
Best regards,
Micha? Górny

Re: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. [ In reply to ]

grobian at gentoo

Jan 10, 2021, 5:54 AM

Post #2 of 7 (147 views)

Permalink

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.

Thanks,
Fabian

> [1] https://bugs.gentoo.org/88596

--
Fabian Groffen
Gentoo on a different level

Re: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. [ In reply to ]

mgorny at gentoo

Jan 10, 2021, 6:47 AM

Post #3 of 7 (147 views)

Permalink

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.

--
Best regards,
Micha? Górny

Re: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. [ In reply to ]

kumba at gentoo

Jan 10, 2021, 2:49 PM

Post #4 of 7 (147 views)

Permalink

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

Re: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. [ In reply to ]

jaco at uls

Jan 11, 2021, 12:52 AM

Post #5 of 7 (147 views)

Permalink

Hi Micha?,

On 2021/01/10 15:34, Micha? Górny wrote:
> Hi,
>
> 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?

3. Have it always use some fixed compiler somewhere (ie, compile it
with CC=/usr/bin/cc-libtool-wrapper CXX=/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=${CC} CC=/usr/bin/cc-libtool-wrapper ...
I'd still add logic to detect the infinite recursion of CC=$0 though ...).

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

Re: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. [ In reply to ]

peter at stuge

Jan 11, 2021, 10:36 AM

Post #6 of 7 (146 views)

Permalink

Jaco Kroon wrote:
> > I can think of two ways of solving it:
> >
> > 1. We could patch system-installed libtool to respect environment
> >
> > 2. We could regenerate libtool and force local instance of libtool
> > in the packages needing it.
>
> 3. Have it always use some fixed compiler somewhere (ie, compile it

4. Make gcc-config regenerate libtool, otherwise as 2.

//Peter

Re: [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc. [ In reply to ]

polynomial-c at gentoo

Jan 17, 2021, 2:55 PM

Post #7 of 7 (143 views)

Permalink

On Mon, 11 Jan 2021 18:36:31 +0000 Peter Stuge wrote:

>Jaco Kroon wrote:
>> > I can think of two ways of solving it:
>> >
>> > 1. We could patch system-installed libtool to respect environment
>> >
>> > 2. We could regenerate libtool and force local instance of libtool
>> > in the packages needing it.
>>
>> 3. Have it always use some fixed compiler somewhere (ie, compile it
>>
>
>4. Make gcc-config regenerate libtool, otherwise as 2.
>
>
>//Peter
>

5.) Try to replace GNU libtool with sys-devel/slibtool

slibtool is aimed to be a drop-in replacement although at the current
state it still has a couple of hiccups. I've created a tracker bug at
[1] to track all issues arising from using slibtool instead of GNU
libtool.

Cheers
Lars

[1] https://bugs.gentoo.org/765709
--
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39

Mailing List Archive

Mailing List Archive

Attached Files: