Re: [gentoo-dev] [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

[Alexis Ballier]

On Thu, 2020-03-12 at 20:59 +0000, James Le Cuirot wrote:
> On Thu, 12 Mar 2020 11:23:04 +0100
> Alexis Ballier <aballier@g.o> wrote:
>
> > On Thu, 2020-03-12 at 09:06 +0100, haubi@g.o wrote:
> > > As this native Win32 support is considered highly experimental
> > > still,
> > > I
> > > would like to apply the libtool patches for parity via
> > > elibtoolize
> > > only,
> > > without applying them in sys-devel/libtool itself yet.
> > >
> >
> > IIRC you need to do it this way, experimental or not: elibtoolize
> > is
> > needed for packages whose autotools have been generated with an old
> > libtool (ie all of them for now). eautoreconf should call
> > elibtoolize,
> > so, after having this in elt-patches, better focus on upstreaming
> > this
> > in libtool itself so that the need for elibtoolize fades away with
> > time.
> >
> > You will probably run into the same issues as in the old days with
> > BSD:
> > not all packages run elibtoolize and you do not have a sane way to
> > force this besides editing ebuilds.
>
> I've long wanted to automatically apply elibtoolize to fix other
> cross-compile issues. I did come up with a rough prototype and it did
> work though I imagine it might break some packages. Maybe it should
> be
> opt-out rather than opt-in?

If a patch in elibtoolize might break something then it should not be
there in the first place: the function is called by a lot of packages.
However, we can assume that such packages have been tested whereas by
magically calling elibtoolize they have not. A good solution to avoid
this could be to modify the default src_prepare in EAPI8 to call it.

I think some hacks were implemented for fbsd via profile.bashrc because
the pain caused by *not* calling elibtoolize (soname changes) was worse
than having untested packages that might break under a red moon.


Alexis.