Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

[Michał Górny]

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