When portage-2.2 (example portage-2.2_rc16) is installed with libtool-1.5.26, some packages fail to compile. Installing libtool-2.2 (example libtool-2.2.6a) fixes this problem. Perhaps libtool-2.x should be a dependency of the newer portage 2.2x. fix described for gnutls: https://bugs.gentoo.org/show_bug.cgi?id=245544 other affected packages: gedit-2.24.2 (4 other packages with I neglected to write down and possibly others) Reproducible: Always Steps to Reproduce: 1. Unmask and install portage-2.2x 2. Forget to unmask libtool-2.x 3. Emerge world, wait for various packages to fail with cryptic libtool errors Actual Results: ../libtool: line 868: X--tag=CC: command not found ../libtool: line 868: X--tag=CC: command not found ../libtool: line 868: X--tag=CC: command not found ../libtool: line 901: libtool: ignoring unknown tag : command not found ../libtool: line 868: X--tag=CC: command not found ../libtool: line 901: libtool: ignoring unknown tag : command not found ../libtool: line 868: X--mode=compile: command not found ../libtool: line 901: libtool: ignoring unknown tag : command not found ../libtool: line 868: X--tag=CC: command not found ../libtool: line 868: X--mode=compile: command not found ../libtool: line 901: libtool: ignoring unknown tag : command not found ../libtool: line 868: X--mode=compile: command not found Expected Results: successfully compile packages...
If the new libtool solves problems with preserved libs, such as bug #244636, that that would give us a reason. However, it seems that problem from bug #245544 was that the gnutls-2.6.0 package itself required the new libtool in order to build (it has since be fixed to build with older libtool). For cases like bug #245544, rather than change portage's dependencies, it would be more appropriate to adjust the dependencies of the relevant package that fails to build, or fix the package to build with older libtool.
I think this would be the wrong approach. When you look at the gnutls bug you referred to, you will see that the _correct_ solution for this bug was not to raise dependency on libtool but rather delete all shipped libtool macros from the source package and regenerate them with help of autotools (eautoreconf). The error is not really the installed/used libtool-version but source-packages shipping pre-generated libtool-macros from other libtool-versions than being installed on your host. Also I don't think the gentoo-devs just put some (for the package itself rather unecessary) dependency on libtool into portage. I think they rather prefer the affected packages getting fixed (as they are supposed to compile with more than just some specific versions of libtool).
(In reply to comment #2) But how is any of this related to portage-2.2 as opposed to any earlier version of portage?
Sorry zac, mid-air collision... comment #2 was my answer to comment #0 I agree with what you wrote in comment #1
