Summary: | x11-libs/gtk+-2.12.12 failed. because of libtool: Version mismatch error.! | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kamen Dokov <polidevk.polidevk> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | The build log |
Description
Kamen Dokov
2008-09-23 03:22:25 UTC
Please attach the full build.log as emerge suggests. Thanks Created attachment 166180 [details]
The build log
Thank ou for your response, uploading the "build.log"
Downgrading to libtool-2.2.4 solves the problem. Im masking libtool 2.2.6a because almost every package brakes with this "version mismatch" error. I think that it`s more likely to be libtool-2.2.6a bug instaed of gtk+ one. (In reply to comment #3) > Downgrading to libtool-2.2.4 solves the problem. > Im masking libtool 2.2.6a because almost every package brakes with this > "version mismatch" error. > I think that it`s more likely to be libtool-2.2.6a bug instaed of gtk+ one. > can't reproduce, could you try again ? (In reply to comment #4) > (In reply to comment #3) > > Downgrading to libtool-2.2.4 solves the problem. > > Im masking libtool 2.2.6a because almost every package brakes with this > > "version mismatch" error. > > I think that it`s more likely to be libtool-2.2.6a bug instaed of gtk+ one. > > > can't reproduce, could you try again ? > gtk+-2.12.12 still fails with libtool-2.2.6a BUT gtk+-2.14.7 installs fine. BUT i`m in the middle of world rebuild and immediately after libtool-2.2.6a was merged dev-libs/dbus-glib-0.78 (from the world rebuild) failed with the same error : libtool: Version mismatch error. This is libtool 2.2.4, but the libtool: definition of this LT_INIT comes from libtool 2.2.6. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.4 libtool: and run autoconf again. this is really strange cause I've been using 2.2.6a since it's been unmasked and never had these problems. plus dbus-glib does an eautoreconf so it should regenerate the aclocal.m4 already. (In reply to comment #6) > this is really strange cause I've been using 2.2.6a since it's been unmasked > and never had these problems. plus dbus-glib does an eautoreconf so it should > regenerate the aclocal.m4 already. > May be something is wrong with file permitions of my libtool and as result upgrade to 2.2.6a is not smooth :( Hi, I had the same problem when emerging courier-authlib I re-emerged libtool-2.2.6a and then i could emerge courier-authlib with no problems closing worksforme. If you can reproduce this problem with a fresh install or a clear upgrade path from libtool 1.5 to 2.2.6a please make sure to reopen this bug and let us know. OK i found out that i have libtool files not only in /usr/share/libtool but in /usr/local/share/libtool also.Those files in local does not get over written during emerge of the new libtool and that were the source of my problems. I emerged libtool-2.2.6a, renamed /usr/local/share/libtool (just in case) and did copy over /usr/share/libtool in to /usr/local/share/. For now everything seems to be ok, but everything will start over again after new libtool release, because /usr/local/share/libtool does not get updated during libtool merge!! that's because stuff in /usr/local gets installed by you and the package manager has no right to touch it. closing invalid since it was a local setup issue after all. OK one last question: How can i prevent new merges to look for libtool in /usr/local/ ? Thank you for your kindness! you can't without making everything else in /usr/local not accessible as well. Binaries on your system are looked up via the PATH variable and /usr/local is in front of it so it "masks" the system's binary for a given program. Same logic applies to some other variables for library lookup path & co, that's why we advise users to never ever install something by hand unless they are advanced users enough to know that, it's generally easy enough to write ebuilds for whatever need you have. (In reply to comment #14) > you can't without making everything else in /usr/local not accessible as well. > Binaries on your system are looked up via the PATH variable and /usr/local is > in front of it so it "masks" the system's binary for a given program. Same > logic applies to some other variables for library lookup path & co, that's why > we advise users to never ever install something by hand unless they are > advanced users enough to know that, it's generally easy enough to write ebuilds > for whatever need you have. > Thank you! I`ll investigate path variable. Best regards: Kamen Dokov |