Currently portage applies lots of libtool patches when building through portage. Native builds using libtool directly does not get any of these which can break builds. Gentoo's native libtool should have the same fixes as portage builds get.
I have no idea what you mean to distinguish with "native" versus "through portage".
(In reply to Jeroen Roovers from comment #1) > I have no idea what you mean to distinguish with "native" versus "through > portage". native: Checking out SW directly from github and running the autoreconf/libool tools manually. portage: build a gentoo pkg using ebuild cmd.
Ping?
To be more specific, the patches in app-portage/elt-patches are only applied when using libtool in an ebuild, should you build src directly these patches are lost. Take /usr/share/elt-patches/cross/2.4.3, this fixes a sysroot bug in official libtool bug never is applied on builds using libtool directly.
ping ?
libtool is a base-system@ package (TIL).
IMO, there is a specific reason for installed /usr/bin/libtoolize to not carry patches that are applied by elibtoolize: Various upstream package maintainers use their Gentoo machines to create their official package distfiles (make dist). It might indeed be fine for their embedded configure and ltmain.sh to carry patches already committed to the libtool upstream repo. But I really believe that other patches may confuse non-Gentoo downstream distro and other package managers, when the package does _pretend_ to carry a specific libtool version, while actually having additional patches applied. In fact, I do prefer packages to even ship known libtool bugs rather than uncommitted libtool patches, so even Gentoo can run elibtoolize against known libtool versions. Otherwise, random libtool patches just ask for a full eautoreconf. To build manually (without an ebuild), you can use the eltpatch command. And on non-Gentoo systems, you can use standalone elt-patches.
(In reply to Michael Haubenwallner from comment #8) > IMO, there is a specific reason for installed /usr/bin/libtoolize to not > carry patches that are applied by elibtoolize: > > Various upstream package maintainers use their Gentoo machines to create > their official package distfiles (make dist). > > It might indeed be fine for their embedded configure and ltmain.sh to carry > patches already committed to the libtool upstream repo. > > But I really believe that other patches may confuse non-Gentoo downstream > distro and other package managers, when the package does _pretend_ to carry > a specific libtool version, while actually having additional patches applied. > > In fact, I do prefer packages to even ship known libtool bugs rather than > uncommitted libtool patches, so even Gentoo can run elibtoolize against > known libtool versions. > > Otherwise, random libtool patches just ask for a full eautoreconf. > > To build manually (without an ebuild), you can use the eltpatch command. > > And on non-Gentoo systems, you can use standalone elt-patches. Patches specific too Gentoo might belong to elibtoolize only, but there are also generic patches that are plain bug fixes too. ATM one can not do cross compiling properly outside the portage system and that is just plain wrong.
If it is still a big concern w.r.t upstream package maintainers, maybe add an USE flag to libtool which adds in the various libtool patches in systems libtool? libtool upstream seems dead so I don't think there is any point asking them to add fixes.
(basically echoing what Michael Haubenwallner already said) we do terrible things in elt-patches, and we do them specifically without thought for how they impact any other environment. if there are specific things you want us to include in our libtool that is in elt-patches, feel free to file specific bugs (one bug per patch/request). Gentoo devs maintaining non-Gentoo projects shouldn't have to worry that building & releasing autotool based projects will include bad logic that doesn't work on non-Gentoo systems.
