I'm just about ready to suggest that we unleash libtool-2.2.4 on at least ~x86 systems. However, I can't figure out how to fix this issue at the moment: % emerge -av apr These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/apr-1.2.12 USE="-debug -doc -ipv6 -urandom" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] yes >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) dev-libs/apr-1.2.12 to / * apr-1.2.12.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking apr-1.2.12.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking apr-1.2.12.tar.gz to /home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.2.12/work * Applying apr-1.2.8-libtool.patch ... [ ok ] * Running eautoreconf in '/home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.2.12/work/apr-1.2.12' ... * Running aclocal -I build ... [ ok ] * Running libtoolize --copy --force --install ... [ ok ] * Running aclocal -I build ... [ ok ] * Running autoconf ... [ !! ] * Failed Running autoconf ! * * Include in your bugreport the contents of: * * /home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.2.12/temp/autoconf-22404.out * ERROR: dev-libs/apr-1.2.12 failed: * Failed Running autoconf ! * * Call stack: * ebuild.sh: 49: <call src_unpack> * environment:2960: <call eautoreconf> * environment: 945: <call eautoconf> * environment: 888: <call autotools_run_tool 'autoconf'> * environment: 413: die "Failed Running $1 !"; * * If you need support, post the topmost build error, and the call stack if relevant. * build log: '/home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.2.12/temp/build.log' * ebuild environment: '/home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.2.12/temp/environment' * S: '/home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.2.12/work/apr-1.2.12' % cat var/tmp/portage/dev-libs/apr-1.2.12/temp/autoconf-22404.out ***** autoconf ***** ***** autoconf configure.in:194: error: possibly undefined macro: LT_VERSION If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. Any takers?
By the way, non-issue with libtool-1.5* "it just works" (tm)
have you tried adding m4_ifdef([LT_VERSION], [LT_VERSION]) to configure.ac (after AM_PROG_LIBTOOL)? It's a wild guess, but the only thing I can come up with.
(In reply to comment #2) > have you tried adding > m4_ifdef([LT_VERSION], [LT_VERSION]) > to configure.ac (after AM_PROG_LIBTOOL)? > > It's a wild guess, but the only thing I can come up with. > Yea, AM_PROG_LIBTOOL doesn't exist and I don't know enough to experiment with other things. There is not upstream bug on this one because in prefix we rm the provided libtool and do some funky stuff in a patch from a year ago. ** Revision 6901, 238 bytes (checked in by grobian, 1 year ago) Use alternative way of fixing libtool problems, by using system libtool.m4, instead of included one, this fixes libtool horror on Solaris, and hopefully Darwin too. ** I removed that patch from the ebuild and tested compilation on x86-linux and: "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." which I have seen before, I'll keep hitting this and see if we can drop that patch eventually.
http://apr.apache.org/download.cgi - apr-1.3.0 is out, maybe that is the best "fix"?
(In reply to comment #4) > http://apr.apache.org/download.cgi - apr-1.3.0 is out, maybe that is the best > "fix"? > With apr-1.3.0: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[1]: *** [passwd/apr_getpass.lo] Error 1
wait, I recall some of that. There is something with that chain of apr, apr-util and subversion where gentoo-x86 did something with libtool. It didn't work, and I patched around it, more or less using more of the upstream method. Later I found out gentoo-x86 way could work too, but I didn't bother to change it. Maybe it's time to change it now :(
For future reference: bug 225783 - "dev-libs/{apr,apr-util}-1.3.0 released"
bug 225983 better describes this 'issue'
(In reply to comment #5) > libtool: compile: unable to infer tagged configuration > libtool: compile: specify a tag with `--tag' > make[1]: *** [passwd/apr_getpass.lo] Error 1 Ugh, this bug will be the death of me. If I apply the "prefix libtool patch" to apr-1.3.0 then I get alittle farther: /bin/sh: /home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.3.0/work/apr-1.3.0/libtool: No such file or directory make[1]: *** [passwd/apr_getpass.lo] Error 127 make[1]: *** Waiting for unfinished jobs.... /bin/sh: /home/jolexa/portage/linux-32/var/tmp/portage/dev-libs/apr-1.3.0/work/apr-1.3.0/libtool: No such file or directory make[1]: *** [strings/apr_cpystrn.lo] Error 127
I just committed a change to the ebuild to be closer to gentoo-x86 version. I could compile apr with libtool-1.5 and libtool-2.2 with that change. Please try if it helps for you too.
(In reply to comment #10) > I just committed a change to the ebuild to be closer to gentoo-x86 version. I > could compile apr with libtool-1.5 and libtool-2.2 with that change. Please > try if it helps for you too. On x86-linux, yes. yay! On amd64-linux, no. apr-1.3 won't build with libtool-1.5. I haven't tried libtool-2.2 yet.
weird, I updated without problems on amd64-linux today...
(In reply to comment #11) > On amd64-linux, no. apr-1.3 won't build with libtool-1.5. I haven't tried > libtool-2.2 yet. Hmm, I can't reproduce the problem today. I'm happy with this now. apr seems much more happy now ;) Thanks for your help.
