| Summary: | x11-libs/gtk+-2.12.9 fails to build with libtool-2.2 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alessandro Guido <ag> |
| Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aballier, polynomial-c, theli.ua |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 212763, 214260 | ||
| Attachments: | gtk+-2-libtool-2.2-fix.patch | ||
|
Description
Alessandro Guido
2008-03-18 08:02:14 UTC
In the ebuild, in src_unpack(): `cp aclocal.m4 old_macros.m4` So it's just like bug 212864 and bug 213715 - updated ltmain.sh and old AC_PROG_LIBTOOL don't work together. (In reply to comment #1) > In the ebuild, in src_unpack(): `cp aclocal.m4 old_macros.m4` > > So it's just like bug 212864 and bug 213715 - updated ltmain.sh and old > AC_PROG_LIBTOOL don't work together. > I patched the ebuild like this and it merged fine (but seems to not work correctly as it misses cups printing support even if the use-flag is enabled): --- x11-libs/gtk+/gtk+-2.12.9.ebuild 2008-03-17 22:24:53.000000000 +0100 +++ local/my-overlay/x11-libs/gtk+/gtk+-2.12.9.ebuild 2008-03-20 22:11:13.000000000 +0100 @@ -87,8 +87,9 @@ # remember, eautoreconf applies elibtoolize. # if you remove this, you should manually run elibtoolize - cp aclocal.m4 old_macros.m4 - AT_M4DIR="." eautoreconf + #cp aclocal.m4 old_macros.m4 + #AT_M4DIR="." eautoreconf + elibtoolize epunt_cxx } The problem is much more difficult and should be be taken upstream. While for gentoo, elibtoolize, eautomake (for multilib patch) and eautoconf (for xinerama - older versions) seem to be needed, and maybe adding gtk-doc-am dependency (probably the original source for `cp aclocal.m4 old_macros.m4` hack), for full eautoreconf much work has to be done upstream. The problem is that in configure.in there are a few calls to the generated libtool, which are invalid for libtool 2.2, unless LT_OUTPUT macro is added. A few more things to add:
it seems that elibtoolize is not needed (it emerged fine without it), but then again it may be needed for something that's not checked during emerge
for libtool 2.2 (and gtk-doc-am) following seens to work:
sed -i -e '/AM_PROG_LIBTOOL/aLT_OUTPUT' ${S}/configure.in
eautoreconf
of course it works for libtool 2.2 only, cause I don't think there was a LT_OUTPUT macro before (as it was not needed then).
elibtoolize is needed for bsd systems at least. Should catch one of these guys to heck out if it is still needed with the new libtool. Created attachment 150589 [details, diff] gtk+-2-libtool-2.2-fix.patch Hi, as this bug is waiting for a fix for over a month now, I started wondering wether gentoo is the only distribution out there who has problems with gtk+ and >=libtool-2.2. I did a rather quick search with google and stumbled about this: http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg135168.html I extracted the real patch from that post, and moved it to my local overlay along with gtk+-2.12.9-r2.ebuild. With this patch I get gtk+-2.12.9-r2 compiled and installed without any problems on my ~x86 test victim erm... machine :) Of course I know that this patch needs upstream approval before it can go into portage but I didn't find this patch anywhere else than in this post... Cheers Poly-C fixed in tree, wait a while for the mirrors to sync and try it. Reopen if it doesn't work. fixed in tree, wait a while for the mirrors to sync and try it. Reopen if it doesn't work. And thanks for the patch. |
