Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
The reason and the effect is similar as in bug 212864, pygobject copies old aclocal.m4 to a different m4 file and runs eautoreconf. As ltmain.sh is updated and AC_PROG_LIBTOOL macro is not, compilation fails at some point. The problem is that I don't know any separate package providing missing macros (cause pygobject does not) and unless I'm missing something, there isn't any and this is an upstream bug.
Please, attach a full emerge log instead of describing errors; thanks.
Like I said, error message is more or less the same as in the above mentioned bug. If they were not filed against different packages, they would be duplicates.
Well, today gtk-doc-am-1.10 package was created to tackle similar problem. Maybe it would be a good idea to create a similar package for programs using JH_* , AM_CHECK_PYMOD and AM_CHECK_PYTHON_HEADERS macros. Or could somebody prod upstream to include those macros ?
please no, if you've read the discussion on irc, the gtk-doc-am is clearly an exception. The rule is that upstream should include all custom macros needed to autoreconf their package. And please let us finish the 2.22 move before continuing on libtool 2.2 bugs.
Well, as far as I can tell, those macros are both custom and non-custom. There seem to be many packages using them (mostly gnome python related) but there does not seem to exist one actually providing it.
OK, the upstream part of this bug will be solved with the next release (http://bugzilla.gnome.org/show_bug.cgi?id=496011). After that only the ebuild will have to be fixed.
upstream bug marked as fixed but pygobject still fails. if /bin/sh ../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/python2.5 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DPY_SSIZE_T_CLEAN -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -march=native -O2 -pipe -fomit-frame-pointer -Wall -fno-strict-aliasing -std=c9x -MT _gobject_la-pygboxed.lo -MD -MP -MF ".deps/_gobject_la-pygboxed.Tpo" -c -o _gobject_la-pygboxed.lo `test -f 'pygboxed.c' || echo './'`pygboxed.c; \ then mv -f ".deps/_gobject_la-pygboxed.Tpo" ".deps/_gobject_la-pygboxed.Plo"; else rm -f ".deps/_gobject_la-pygboxed.Tpo"; exit 1; fi ../libtool: line 463: CDPATH: command not found ../libtool: line 463: CDPATH: command not found ../libtool: line 1148: func_opt_split: command not found ../libtool: line 1148: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.4, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.4 libtool: and run autoconf again. libtool: Version mismatch error. This is libtool 2.2.4, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.4 libtool: and run autoconf again. i tried patch from http://bugzilla.gnome.org/show_bug.cgi?id=496011#c3 but doesn't help at all. i think this bug somehow similar to http://bugs.gentoo.org/show_bug.cgi?id=212718
You failed to understand my answer. The upstream did fix it, but that change is not yet released. When it gets released, all that will need to be done, will be changing in the ebuild: cp aclocal.m4 old.m4 AT_M4DIR="." eautoreconf to simply: eautoreconf
Actually to AT_M4DIR="m4" eautoreconf
Created an attachment (id=152533) [details] pygobject-9999.ebuild ok, i've made live ebuild i think it may be used as temporary solution until next pygobject release
Well, no got bored and tested it. There's one more issue. configure.ac contains that silly check for a libtool variable, by running `libtool --config`. Temporary fix would be adding LT_OUTPUT for libtool 2.*. But it's the same issue as in gtk+, probably this var can be checked directly. I'll test it.
Created an attachment (id=152553) [details] A (nearly) trivial patch solving final libtool This works fine for libtool 2.*, but a certain comment on libtool mailing list suggest it should work for 1.5.*. Anybody willing to check ?
Patch doesn't help, different error message now: applied patch: nano /var/tmp/portage/dev-python/pygobject-2.14.1/work/pygobject-2.14.1/configure.ac (exchanged line 137) and did a ebuild /usr/portage/dev-python/pygobject/pygobject-2.14.1.ebuild compile ... config.status: creating PKG-INFO config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands configure: WARNING: Unrecognized options: --disable-gtk-doc libffi support: disabled cd . && /bin/sh /var/tmp/portage/dev-python/pygobject-2.14.1/work/pygobject-2.14.1/missing --run aclocal-1.9 -I m4 -I . aclocal: couldn't open directory `m4': No such file or directory make: *** [aclocal.m4] Error 1 * * ERROR: dev-python/pygobject-2.14.1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2944: Called gnome2_src_compile * environment, line 2220: Called die * The specific snippet of code: * emake || die "compile failure" * The die message: * compile failure * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-python/pygobject-2.14.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/pygobject-2.14.1/temp/environment'. * **************************** pygobject-9999.ebuild won't work neither ... pygobject # ebuild /usr/portage/dev-python/pygobject/pygobject-9999.ebuild compile >>> Existing ${T}/environment for 'pygobject-9999' will be sourced. Run >>> 'clean' to start with a fresh environment. * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * * ERROR: dev-python/pygobject-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2982: Called subversion_src_unpack * environment, line 3226: Called subversion_fetch * environment, line 3117: Called built_with_use '--missing' 'true' '-o' 'dev-util/subversion' 'webdav-neon' 'webdav-serf' * environment, line 478: Called die * The specific snippet of code: * [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"; * The die message: * Unable to resolve dev-util/subversion to an installed package * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-python/pygobject-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/pygobject-9999/temp/environment'. *
(In reply to comment #13) > * The die message: > * Unable to resolve dev-util/subversion to an installed package install subversion first
I like to wait for the fixed patch of pygobject. Thanks.
Created an attachment (id=152583) [details] pygobject-9999.ebuild subversion dependency added
To clarify, AT_M4DIR="m4" will work, when the new release comes, cause now the macros are not in the tarball. As for myself, I simply got those macros, cat'ed them into acinclude.m4, in the current ebuild substed `cp aclocal. m4 ...` line with cp "${FILESDIR}"/acinclude.m4 "${S}"/acinclude.m4 added `epatch "${FILESDIR}"/exp_dyn.patch` after libffi patch and reduced eutoreconf block to simply eutoreconf, and it works for me.
I've got the same problem. emerge -pv pygobject These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-python/pygobject-2.14.1 USE="-debug -doc -examples" 0 kB started to build but failed! some interesting from build messages ................................................... config.status: executing depfiles commands configure: WARNING: Unrecognized options: --disable-gtk-doc libffi support: disabled cd . && /bin/sh /var/tmp/portage/dev-python/pygobject-2.14.1/work/pygobject-2.14.1/missing --run autoheader autoheader-2.62: cannot create `pwd`/pygobject-2.14.1/ah2753.6273: Нет такого файла или каталога at /usr/bin/autoheader-2.62 line 129 WARNING: `autoheader' is missing on your system. You should only need it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in ...................... ........................ * ERROR: dev-python/pygobject-2.14.1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2936: Called gnome2_src_compile * environment, line 2212: Called die * The specific snippet of code: * emake || die "compile failure" * The die message: * compile failure ..................... Portage 2.1.5.2 (default/linux/x86/2008.0, gcc-4.3.0, glibc-2.7-r2, 2.6.24-16-generic i686) ================================================================= System uname: 2.6.24-16-generic i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz Timestamp of tree: Thu, 22 May 2008 05:00:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.4-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.25-r3 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer -mfpmath=sse -mssse3" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer -mfpmath=sse -mssse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="ru_RU.UTF-8" LDFLAGS="" LINGUAS="ru en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="7zip X acl acpi alsa bzip2 cli cracklib crypt dbus djvu dri firefox fortran gdbm gif glib gpm hal iconv isdnlog java jpeg jpeg2k kde laptop libssh2 midi mmx motif mudflap ncurses nls nptl nptlonly opengl openmp pam pcre perl plugins png python qt3 qt4 readline reflection session smartcard spl sse2 ssl svg synaptics tcpd threads tiff truetype udev unicode x86 xcomposite xml xorg xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="ru en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY (In reply to comment #0) > The reason and the effect is similar as in bug 212864, pygobject copies old > aclocal.m4 to a different m4 file and runs eautoreconf. As ltmain.sh is updated > and AC_PROG_LIBTOOL macro is not, compilation fails at some point. > The problem is that I don't know any separate package providing missing macros > (cause pygobject does not) and unless I'm missing something, there isn't any > and this is an upstream bug. >
This seems completely unrelated. Not only you failed to post the actual failure, but it seems that either your autoconf or autoconf-wrapper is broken (that autoheader message).
As 2.14.2 was finally released, feel free to close this bug.
indeed, it now works properly. Closing.
