Summary: | dev-libs/apr-1.5.1-r1 with =sys-devel/libtool-2.4.3 - libtool: Version mismatch error. This is libtool 2.4.3, but the definition of this LT_INIT comes from libtool 2.4.2. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Timo Gurr (RETIRED) <tgurr> |
Component: | [OLD] Library | Assignee: | Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, base-system, bugs+gentoo, ecyoung, ghutzl, karl.j.linden, krinpaus, lists, moonwalker, naota, nholland, patrakov, solor, toralf, wizardedit, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 529580 | ||
Attachments: |
build.log
patch for apr to work with libtool 2.4.3 fixed .ebuild with simple sed to change libtool version apr-1.5.0-r2.ebuild.patch autotools.eclass.patch autotools.eclass.patch |
Description
Timo Gurr (RETIRED)
2014-10-30 17:34:37 UTC
Created attachment 387822 [details]
build.log
*** This bug has been marked as a duplicate of bug 527200 *** Same issue with sys-devel/libtool-2.4.3-r1 Created attachment 387946 [details, diff]
patch for apr to work with libtool 2.4.3
took ltmain.sh and ltversion.m4 from libtool 2.4.3, fixed configure and created diff... however it must be some other way to fix this?
*** Bug 527924 has been marked as a duplicate of this bug. *** Created attachment 388328 [details]
fixed .ebuild with simple sed to change libtool version
No need for that patch, since ebuild it self takes care for ltmain.sh and ltversion.m4... only needs fixing libtool version inside configure, for which simple sed is enough.
The source includes a small script to prepare for building that can be invoked with "./buildconf". The script runs a python script so a python dependency has to be added. Running the script before building fixes this bug. Here is a patch that fixes the bug. --- apr-1.5.1-r1.ebuild 2014-04-28 15:26:43.000000000 +0200 +++ apr-1.5.1-r2.ebuild 2014-11-02 17:41:03.739967990 +0100 @@ -4,7 +4,8 @@ EAPI=5 -inherit autotools eutils libtool multilib toolchain-funcs +PYTHON_COMPAT=( python2_7 ) +inherit autotools eutils libtool multilib python-any-r1 toolchain-funcs DESCRIPTION="Apache Portable Runtime Library" HOMEPAGE="http://apr.apache.org/" @@ -18,6 +19,7 @@ RDEPEND="elibc_glibc? ( >=sys-apps/util-linux-2.16 ) elibc_mintlib? ( >=sys-apps/util-linux-2.18 )" DEPEND="${RDEPEND} + ${PYTHON_DEPS} >=sys-devel/libtool-2.4.2 doc? ( app-doc/doxygen )" @@ -32,6 +34,20 @@ epatch_user #449048 + python_fix_shebang build/gen-build.py + ebegin "Running ./buildconf" + ./buildconf >> "${T}/buildconf.log" 2>&1 + if ! eend $? ; then + echo + eerror "Failed Running ./buildconf !" + eerror + eerror "Include in your bugreport the contents of:" + eerror + eerror " ${T}/buildconf.log" + echo + die "Failed Running ./buildconf !" + fi + AT_M4DIR="build" eautoreconf elibtoolize ...:sigh:... For various reasons - some of them have even been noted in older dev-libs/apr bugs - buildconf is not to be used by the ebuild. Also, that script should (more or less) have the same result (at least wrt. to libtool) as eautoreconf. Funny thing - it seems I can't reproduce this outside portage: libtoolize --copy --force aclocal -I build autoconf -I build autoheader -I build results in a correctly updated tarball. So, is build/ltversion.m4 after src_prepare one from libtool 2.4.3 ? The weird part is that no aclocal.m4 is being created and build/ltversion.m4 is just about explicitly updated by libtoolize, so there should be no source for the stale macro. FWIW, this bug do affect older ebuild versions too, eg =dev-libs/apr-1.5.0-r2::gentoo Hmm.. libtool bug? ltversion.m4 from libtool 2.4.2: m4_define([LT_PACKAGE_VERSION], [2.4.2]) m4_define([LT_PACKAGE_REVISION], [1.3337]) AC_DEFUN([LTVERSION_VERSION], [macro_version='2.4.2' macro_revision='1.3337' _LT_DECL(, macro_version, 0, [Which release of libtool.m4 was used?]) _LT_DECL(, macro_revision, 0) ]) ltversion.m4 from libtool 2.4.3: m4_define([LT_PACKAGE_VERSION], [2.4.2.458.26-92994]) m4_define([LT_PACKAGE_REVISION], [2.4.3]) AC_DEFUN([LTVERSION_VERSION], [macro_version='2.4.2.458.26-92994' macro_revision='2.4.3' _LT_DECL(, macro_version, 0, [Which release of libtool.m4 was used?]) _LT_DECL(, macro_revision, 0) ]) Yeah. libtool's upstream released broken tarball. After running bootstrap ltversion.m4 looks fine: m4_define([LT_PACKAGE_VERSION], [2.4.3]) m4_define([LT_PACKAGE_REVISION], [2.4.3]) AC_DEFUN([LTVERSION_VERSION], [macro_version='2.4.3' macro_revision='2.4.3' _LT_DECL(, macro_version, 0, [Which release of libtool.m4 was used?]) _LT_DECL(, macro_revision, 0) ]) Err.. Please ignore my comments. Fixing ltversion.m4 in libtool doesn't fix apr. Created attachment 389064 [details, diff]
apr-1.5.0-r2.ebuild.patch
Run libtoolize before regenerating configure. Not sure why eautoreconf does not do that. This patch fixes build error.
(In reply to Alexander Tsoy from comment #13) > Created attachment 389064 [details, diff] [details, diff] > apr-1.5.0-r2.ebuild.patch > > Run libtoolize before regenerating configure. Not sure why eautoreconf does > not do that. This patch fixes build error. The patch works for dev-libs/apr-1.5.1-r1 as well for me, with libtool-2.4.3-r2. The patch adding _elibtoolize works for me Created attachment 389256 [details, diff] autotools.eclass.patch (In reply to Alexander Tsoy from comment #13) > Created attachment 389064 [details, diff] [details, diff] > apr-1.5.0-r2.ebuild.patch > > Run libtoolize before regenerating configure. Not sure why eautoreconf does > not do that. This patch fixes build error. Actually eautoreconf() also calls _elibtoolize(), but (probably) autotools_check_macro() from autotools.eclass generates autom4te.cache before _elibtoolize() is called. Autoconf uses that cache to generate configure instead of reading updated m4 files. Attached patch for autotools.eclass also fixes this bug. Note that the patch I've attached for autotools.eclass is just a PoC. Maybe cache should be better removed in eautoreconf() instead. @base-system: What do you think? How this bug should be fixed? By adding _elibtoolize in ebuild or by removing autom4te.cache in autotools.eclass? Created attachment 389294 [details, diff]
autotools.eclass.patch
Sorry, I forgot about --force
Added myself as I'm experiencing same issue, even with: make[1]: Entering directory '/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1' /var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/build/mkdir.sh tools /bin/sh /var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/libtool --silent --mode=compile x86_64-pc-linux-gnu-gcc -pthread -march=amdfam10 -O2 -pipe -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -I./include -I/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/include/arch/unix -I./include/arch/unix -I/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/include/arch/unix -I/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/include -I/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/include/private -I/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/include/private -o tools/gen_test_char.lo -c tools/gen_test_char.c && touch tools/gen_test_char.lo libtool: Version mismatch error. This is libtool 2.4.3, but the libtool: definition of this LT_INIT comes from libtool 2.4.2. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.3 libtool: and run autoconf again. Makefile:134: recipe for target 'tools/gen_test_char.lo' failed make[1]: *** [tools/gen_test_char.lo] Error 63 make[1]: Leaving directory '/var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1' /var/tmp/portage/dev-libs/apr-1.5.1-r1/work/apr-1.5.1/build/apr_rules.mk:118: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 * ERROR: dev-libs/apr-1.5.1-r1::gentoo failed (compile phase): * emake failed I need libtool 2.4.3. I cannot downgrade etc, so would someone commit this to the tree + 15 Nov 2014; Lars Wendler <polynomial-c@gentoo.org> apr-1.5.1-r1.ebuild: + Added kludge to fix compilation with >=libtool-2.4.3 until autotools.eclass + got fixed (bug #527506). + Keeping this bug open until autotools.eclass got fixed. + 12 Jan 2015; Lars Wendler <polynomial-c@gentoo.org> autotools.eclass: + Use "--force" when running eautoconf through eautoreconf (bug #527506). + |