On Thu, 2020-03-12 at 20:59 +0000, James Le Cuirot wrote: > On Thu, 12 Mar 2020 11:23:04 +0100 > Alexis Ballier <aball...@gentoo.org> wrote: > > > On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org 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.
