Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 212763 (libtool-2.2) - [Tracker] sys-devel/libtool-2.2 breakage
Summary: [Tracker] sys-devel/libtool-2.2 breakage
Alias: libtool-2.2
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Keywords: Tracker
: 212826 (view as bug list)
Depends on: 227241 205018 212718 212721 212723 212750 212755 212760 212772 212777 212811 212864 212903 213715 213789 213800 213805 213831 215843 216110 218295 218444 218483 218666 218982 219696 220114 220339 220353 220361 220519 220543 220549 220565 220599 220681 220703 220755 220765 220819 220825 220887 221041 221149 221275 221879 222345 226127 226457 226461 226525 227239 227299 228183 228213 228265 228439 228441 228753 228831 228873 229055 229443 229821 229901 230271 230780 230853 231767 232568 234258 235025 235425 237611 239654 241578 243452 245544 272681 273975 276194 277418 279589
Blocks: 257399
  Show dependency tree
Reported: 2008-03-08 22:12 UTC by Jakub Moc (RETIRED)
Modified: 2012-06-26 04:02 UTC (History)
24 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2008-03-08 22:12:47 UTC
Tracking sys-devel/libtool-2.2 borkage here.
Comment 1 teidakankan 2008-03-09 00:30:04 UTC

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:
 *     , 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'
 *     , line  513:  Called die
 * The specific snippet of code:
 *                      die "econf failed"
 *  The die message:
 *   econf failed
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2008-03-09 08:24:25 UTC
(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.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2008-03-09 15:12:28 UTC
*** Bug 212826 has been marked as a duplicate of this bug. ***
Comment 4 Ben de Groot (RETIRED) gentoo-dev 2008-03-10 21:22:14 UTC
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...
Comment 5 Mart Raudsepp gentoo-dev 2008-04-02 07:48:29 UTC
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.
Comment 6 Ben de Groot (RETIRED) gentoo-dev 2008-05-05 10:35:13 UTC
Why was libtool-2.2 removed from package.mask without an entry in the ChangeLog nor here? It's clearly still causing some breakage...
Comment 7 Peter Volkov (RETIRED) gentoo-dev 2008-05-05 11:55:17 UTC
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...
Comment 8 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2008-05-05 11:59:33 UTC
(In reply to comment #7)
> apache
Comment 9 Michael Haubenwallner (RETIRED) gentoo-dev 2008-05-05 13:01:16 UTC
(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 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()...
Comment 10 SpanKY gentoo-dev 2008-05-05 13:32:07 UTC
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.
Comment 11 Mart Raudsepp gentoo-dev 2008-05-07 13:45:27 UTC
(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.
Comment 12 Chad A. Simmons 2008-05-08 16:44:32 UTC
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.
Comment 13 SpanKY gentoo-dev 2008-05-10 09:07:26 UTC
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.
Comment 14 subs 2008-05-10 15:24:18 UTC
I would like to add x11-misc/rss-glx to this bug. See
Comment 15 Kyle Elbert 2008-05-10 21:49:24 UTC
@the previous commenter
have you tried building it with libtool 2.2.x since that bug was filed??
Comment 16 subs 2008-05-10 22:54:45 UTC
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.
Comment 17 Roby 2008-05-22 21:41:24 UTC
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.
Comment 18 SpanKY gentoo-dev 2008-05-31 06:29:58 UTC
not really ... it'd make things worse in the long run
Comment 19 subs 2008-06-09 23:27:51 UTC
libtool 2.2.4 is unmasked again and the rss-glx breakage still exists.
Comment 20 PetaMem R&D 2008-06-18 08:08:34 UTC
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.
Comment 21 SpanKY gentoo-dev 2008-06-18 09:28:57 UTC
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.
Comment 22 PetaMem R&D 2008-06-18 10:23:58 UTC
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 ;-))
Comment 23 Fabian Groffen gentoo-dev 2008-06-18 10:27:46 UTC
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.
Comment 24 SpanKY gentoo-dev 2008-06-18 10:31:19 UTC
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.
Comment 25 Holger Hoffstätte 2008-06-18 10:42:49 UTC
(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.
Comment 26 Ben de Groot (RETIRED) gentoo-dev 2008-06-18 13:17:16 UTC
(In reply to comment #22)
Why the fuck did you remove all the people from the CC list? This is vandalism!
Comment 27 SpanKY gentoo-dev 2008-06-18 13:32:57 UTC
please refrain from using such language.  he made a big mistake; let's not pollute the bug any further.
Comment 28 SpanKY gentoo-dev 2009-11-16 19:36:21 UTC
seems to be all set now, and we're stable