Tracking sys-devel/libtool-2.2 borkage here.
libgphoto2-2.4.0-r1 checking ltdl.h usability... yes checking ltdl.h presence... yes checking for ltdl.h... yes checking for lt_dlcaller_register in -lltdl... no configure: error: libgphoto2 requires the ltdl library, included with libtool Please make sure that the proper development package is installed (libltdl-dev, libtool-ltdl-devel, etc.) !!! Please attach the following file when seeking support: !!! /var/tmp/portage/media-libs/libgphoto2-2.4.0-r1/work/libgphoto2-2.4.0/config.log * * ERROR: media-libs/libgphoto2-2.4.0-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2578: Called econf 'src_compile' 'src_compile' '--with-drivers=sony_dscf1,sony_dscf55' '--with-doc-dir=/usr/share/doc/libgphoto2-2.4.0-r1' '--with-html-dir=/usr/share/doc/libgphoto2-2.4.0-r1/html' '--with-hotplug-doc-dir=/usr/share/doc/libgphoto2-2.4.0-r1/hotplug' '--enable-nls' '--with-rpmbuild=/bin/true' '--disable-docs' 'udevscriptdir=/lib/udev' * ebuild.sh, line 513: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed
(In reply to comment #1) This is a tracker bug *only*, we have Bug 212721 for libgphoto2. Please don't paste error logs here, file separate bugs.
*** Bug 212826 has been marked as a duplicate of this bug. ***
I forgot to add this to the bug at the time, but I package.masked this on Saturday night, when the bugs started to flood in. No-one seemed to be around in #gentoo-dev or #gentoo-bugs to fix this. I found this important enough for our users, that I took it upon myself. Sorry if I stepped on anyone's toes...
I upgraded the mask to include libtool-2.2.2 bump, to continue keeping away major breakage from our users until the widely used packages are fixed or libtool stops being so strict.
Why was libtool-2.2 removed from package.mask without an entry in the ChangeLog nor here? It's clearly still causing some breakage...
I agree with Ben here. I have not filled bugs, but unixODBC, apache are the packages which fail with libtool-2.22 too. I'm sure there many similar packages. Actually seems that most of packages which ran libtoolize and contain old libtool m4 file (normally inside acinclude.m4 together with other macroses) are broken... and things even worth in case package includes libltdl. Also yes, ChangeLog should be either updated every time we do changes or there should be no ChangeLog...
(In reply to comment #7) > apache https://issues.apache.org/bugzilla/show_bug.cgi?id=44817
(In reply to comment #7) > ... and contain old libtool m4 file ... Would it be reasonable to have eautoreconf() also update local libtool.m4 (if any), as it already does for ltmain.sh via {_e,}libtoolize ? This also would help in Prefix, where we need to have local libtool.m4 to be at least 1.5.24 to know Interix fex. Currently, in such cases we manually copy usr/share/aclocal/libtool.m4 (1.5.26 by now) in place before eautoreconf()...
if people arent filing bugs, then the issue never gets fixed. leaving it in package.mask means it stays masked forever because people are worried about breakage they have no idea exists. we unmask it and if *a lot of things* are broken, we can put it back in. otherwise, you fix the broken packages instead of punishing the wrong package. seems fairly straight forward to me.
(In reply to comment #10) > if people arent filing bugs, then the issue never gets fixed. See the dependency list. > leaving it in > package.mask means it stays masked forever because people are worried about > breakage they have no idea exists. > > we unmask it and if *a lot of things* are broken, we can put it back in. > otherwise, you fix the broken packages instead of punishing the wrong package. > seems fairly straight forward to me. There are SIXTEEN broken packages known and filed and depending on the breakage bug that this one is. This is not a number that makes it reasonable to break everyones ~arch system when it's KNOWN broken. KNOWN breaking lots of things == belongs in package.mask. As straight forward as that.
Could an ewarn be added to the ebuild referencing this bug? Some users(myself included) might not notice that the new libtool rev was pulled in. Atleast if there was an ewarn I would have noticed the email sent by portage. It seems like ewarns have been used in other packages that are known to cause issues.
the large majority of those were not filed when libtool was in package.mask. that means your "known lots of things" statement is wrong. if it's in package.mask and no one is reporting bugs, nothing is known. i'll keep unmasking things so long as the # of broken packages goes low. i also wont sit around while people do nothing to fix their packages because then it'll never come out of package.mask. instead of complaining about libtool, you should be fixing the packages in question. after all, libtool itself isnt the thing broken ... it's packaging using libtool incorrectly.
I would like to add x11-misc/rss-glx to this bug. See http://bugs.gentoo.org/show_bug.cgi?id=220825
@the previous commenter have you tried building it with libtool 2.2.x since that bug was filed??
If you are referring to me, I am not sure what you are asking. It builds with libtool 1.5.26 but doesn't get past configure with 2.2.4.
Is it possible to make libtool 1.5.x and 2.2.x be in separate slots? I think it would save a lot of headaches.
not really ... it'd make things worse in the long run
libtool 2.2.4 is unmasked again and the rss-glx breakage still exists.
libtool 2.2.4 is an utter mess! It doesn't work on any single Gentoo installation here at the company (and believe me, there are many). It breaks every apache2 compilation and many others, it puts itself in the 1.5 slot, lots of people seem to have problems with it. 1.5.26 works perfect for us so far. A breakage it is. We've given all remaining votes to this.
this is not the place to air your complaints. if a package is broken, it is broken, not libtool. open a bug so it'll get fixed. it really doesnt matter if you vote for this bug seeing as how there's nothing to be changed in libtool itself. also, i'd question the logic behind running unstable in a corporate setting. unstable will break, and libtool is hardly the biggest.
Ok, let's get the facts right: libtool 2.2.4 breaks building apache 2.2.8 and 2.2.9; proftpd, imlib, libgdiplus, mdbtools, subversion, rxtx,... well and so on and so on. The number SIXTEEN packages was mentioned before here. SpanKY keeps telling us, the problem is not libtool, but all these packages that break. Actually, in a democratic environment this argumentation is invalid. But let's assume for a moment SpanKY is right. Libtool is correct and all these packages such as apache and subversion are broken. It's evidently incompatible to the 1.5.26 but let's further assume, putting the 2.2.4 into the 1.5 slot is also ok because else it would "cause more problems in the long run". Why is 2.2.4 causing so much trouble anyway? I mean upgrading baselayout from 1.12 to 2.0 was a walk in the park against this. Why is it then not hard masked then if it's such a big incompatible upgrade? What's this **9999 version kludge there? I admit not to know the exact technical inertiae of this package, but there's already quite some Gentoo Linux-specific competence here. Gentoo runs here on Notebooks, Big Iron Servers, regular Desktops and VMs. And this package - libtool 2.2.4 - is causing constantly problems, so now it is masked by default on every new install. I only visited Gentoo Bugzilla for libtool, because I wanted to know the reason why this problem persists for such a long time. Please hard mask 2.2.4 BTW: We're not running "unstable" in our corporate setting as you suggest. Accepting x86 on x86 has proven to be very stable for quite some time now (ok except libtool - you win ;-))
Who on earth are you that you think you are legitimately removing everyone CC-ed to this bug? Go complain somewhere else, and help us identify and fix the packages that do not cope with the latest libtool.
well, i guess it's a good thing it isnt a democratic process around here. the right answer wins, not what people who vote on what they *think* the right answer is.
(In reply to comment #22) > Ok, let's get the facts right: Yes, that would be great. > BTW: We're not running "unstable" in our corporate setting as you suggest. - libtool-2.2.4 _is_ marked unstable; you are contradicting yourself. - most "unstable" packages (such as apache) have already been fixed to build & work just fine with libtool-2.2.4; I'm running most of them. In "production". - hardmasking does not fix anything; fixing does. You can help, for example by visiting bugzilla more often.
(In reply to comment #22) Why the fuck did you remove all the people from the CC list? This is vandalism!
please refrain from using such language. he made a big mistake; let's not pollute the bug any further.
seems to be all set now, and we're stable