libwww does not compile, cannot find autoconf dependency. libwww needs autoconf-2.50 but cannot find autoconf-2.57-r1 Reproducible: Always Steps to Reproduce: 1. emerge libwww 2. 3. Actual Results: creating Icons/Makefile creating Icons/WWW/Makefile creating Icons/32x32/Makefile creating Icons/internal/Makefile creating wwwconf.h cd . && aclocal cd . && automake --foreign --include-deps Makefile cd . && autoconf FATAL ERROR: Autoconf version 2.50 or higher is required for this script make: *** [configure] Error 2 !!! ERROR: net-libs/libwww-5.4.0-r1 failed. !!! Function src_compile, Line 48, Exitcode 2 !!! (no error message) Expected Results: autoconf-2.57-r1 should have been found & accepted #emerge -s autoconf * sys-devel/autoconf Latest version available: 2.57-r1 Latest version installed: 2.57-r1 Size of downloaded files: 1,225 kB Homepage: http://www.gnu.org/software/autoconf/autoconf.html Description: Used to create autoconfiguration files Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.23_pre8-gss)================================================================= System uname: 2.4.23_pre8-gss i586 AMD-K6(tm) 3D processor Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=k6-2 -march=i586 -O3 -pipe -fomit-frame-pointer" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-mcpu=k6-2 -march=i586 -O3 -pipe -fomit-frame-pointer" DISTDIR="/home/scratch/distfiles" FEATURES="ccache autoaddcvs -sandbox" GENTOO_MIRRORS="ftp://mirror.pacific.net.au/linux/Gentoo http://mirror.pacific.net.au/linux/Gentoo ftp://planetmirror.com/pub/gentoo/ http://planetmirror.com/pub/gentoo/ rsync://planetmirror.com/gentoo/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/home/scratch/portage_tmpdir" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode gif gtk2 jpeg libg++ libwww mad mikmod mpeg nls oggvorbis quicktime sdl svga xv zlib gdbm berkdb slang readline tcpd pam perl python esd imlib -3dfx 3dnow -aalib -acl -acpi -afs -altivec -arts -atlas -bidi -canna -cjk -cscope -curl -debug -dvb -emacs evo -freewnn gnome gpm foomaticdb gtk gtkhtml -kde -qt -motif mysql ncurses opengl pdflib png perlreadline scanner spell ssl truetype usb X xml2 xmms video_cards_rage128"
*** Bug 35328 has been marked as a duplicate of this bug. ***
using libwww-5.4.0-r2 and autoconf-2.58.ebuild does not work either (same error). "man autoconf" tells me that "autoconf -V" should return the version number. It doesn't: # autoconf -V Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir] [-l dir] [--localdir=dir] [--version] [template-file]" # autoconf --version Autoconf version 2.13 #emerge -s autoconf sys-devel/autoconf Latest version available: 2.57-r1 Latest version installed: 2.58 OK so is that a bit weird/wrong? I have autoconf-2.58 installed but autoconf is reporting itself to be autoconf-2.13...? As far as I can tell this relates directly with the error I am recieving. Can anybody else verify that autoconf-2.58 and/or autconf-2.57* give incorrect version numbers? Does any of this info help...?
Recent sys-devel/autoconf changed environment variable fromWANT_AUTOCONF_2_5=1 to WANT_AUTOCONF=2.5 (In some cases autoconf wrapper script cannot determine whichversion to apply automatically, so we need these variables toforce preferred version).I committed the change accordingly. Please emerge sync andtry again.
Usata, that's odd, I tried it with WANT_AUTOCONF=2.5 locally here, which seemed to break the build for me, although it worked fine without specifying that.
Usata, that fix is not right, I think. Here is what I get with your fix: creating Icons/Makefile creating Icons/WWW/Makefile creating Icons/32x32/Makefile creating Icons/internal/Makefile creating wwwconf.h cd . && aclocal cd . && automake --foreign --include-deps Makefile cd . && autoconf aclocal.m4:267: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/c.m4:1092: AC_C_VOLATILE is expanded from... aclocal.m4:267: the top level autom4te-2.57: /usr/bin/m4 failed with exit status: 1 make: *** [configure] Error 1 make: *** Waiting for unfinished jobs.... !!! ERROR: net-libs/libwww-5.4.0-r2 failed. !!! Function src_compile, Line 59, Exitcode 2 !!! (no error message) $ epm -q autoconf autoconf-2.57-r1
libwww-5.4.0-r1 works fine for me with WANT_AUTOCONF=2.1 WANT_AUTOCONF_2_1=yes
Hi everyone. I am totally new to bugzilla and no expert at programming. I have been using gentoo for a while now though. I hope my comments here are appropriate! please let me know if I should post more or less info! I am getting the same error as comment number 5 same message exactly except there is no make: *** Waiting for unfinished jobs.... at the bottom (kind of doubt that is significant) I am almost wondering if this is a totally seperate bug though as this is with version 5.4.0-r2 while the initial post was regaurding 5.4.0-r1. I have been chasing this around my machine for about 2 hours now but I don't know much about autoconf or any of the other stuff that is happening when the error hits. just wanted to make sure that people noted that comment #5 was about a different version. should I be making a seperate bug report on this issue?
Okay summary: Our original error is that libwww-5.4.0-r2 claims it requres autoconf >= 2.5 to build, but doesnt find autoconf-2.57 on the reporters system. WANT_AUTOCONF="2.5" is then specified in the ebuild. This fix breaks at least 3 builds of libwww-5.4.0-r2 (Aron, Kelly, and mine). Aron claims building libwww-5.4.0-r1 works with WANT_AUTOCONF="2.1", but fails to mention whether this works with libwww-5.4.0-r2, or whether it also fixes the original problem. Here's what we need, and from whom. Brett: does the WANT_AUTOCONF="2.5" fix _actually_ fix things for you ? Aron: did you have the original problem ? (first sentence above). Could you please both report. I'm inclined to revert the WANT_AUTOCONF="2.5" fix, on account of it breaks builds, and look for a real solution to the original problem unless either of you report otherwise. (Kelly: comments are always appreciated, please use bugzilla and add informative reports (like you have). Remember to add yourself to the CC!)
The WANT_AUTOCONF="2.5" has not fixed the original (my) problem. With the recent ebuild I am getting the same error as comment #5 In that case it is probably best to revert the ebuild (so that it works for most people) until another fix can be found I guess...
Sorry for breaking so many ebuilds :-/ I checked what I did and found I editted libwww-5.2.0-r2.ebuild and emerged libwww-5.2.0-r1.ebuild (and it emerged fine, obviously). Now I got the same error as described in comment #5. (I hadn't any problem with -r1 and -r2 before using autoconf-2.57-r1) I edited libwww-5.2.0-r2.ebuild because it is marked as unstable and want to change stable ebuild (libwww-5.2.0-r1.ebuild) as less as possible. Changing ebuilds like this may break emerging (and it happend, my apologies). Now I've looked at the configure.in and it says autoconf-2.13 is required (this is supported by the fact that WANT_AUTOCONF=2.1 and WANT_AUTOCONF_2_1=1 worked fine as agriffis pointed out). I don't know why the original error says it needs autoconf-2.5... Obz, please revert what I did to the ebuild. At least the original one emerged fine.
thought this might be interesting: There is a thread in the forums where they mention this and they seem to talk about a work around. I haven't tried it yet myself so I can't confirm/deny maybe later tonight I will have time. the thread is at: http://forums.gentoo.org/viewtopic.php?t=114062&highlight=libwww they also link to some thread about an alsa bug... haven't had time to figure how that relates yet. I posted a link back here in case THEY were interested (I am uglyman).
I had some time to revert the last change, so I did it by myself.(Just FYI, we usually don't bump ebuild's revision if it is only compilation problem,see also chap3sect2 of Gentoo Linux Development Policy)
In the thread I mentioned in comment #11, bwins suggests a workaround that I can now confirm works on my system. # he says to change the lines that set WANT_AUTOCONF_2_5=1 WANT_AUTOCONF=2.5 # to WANT_AUTOCONF_2_5="no" WANT_AUTOCONF="2.1" This is all to be done on the -r2 ebuild. I was careful to make sure this is the one I edited AND emerged, as someone else mentioned confusion there. I did this by specifying an absolute path with emerge. I then got curious if both these settings were critical. In comment #3 I read that they had changed from one var to the other so I thought maybe only one was critical to a particular system. I figured maybe it just depended if you installed autoconf before or after the change. What I found was that BOTH settings ARE critical. I tried different combinations of one old, and one new, of the two settings. It seems both come into play, so both must be changed for the emerge to be successful. I also wondered about the difference between =0 =1 type values and ="no" ="yes". It appears that both are acceptable. I noticed no change when swapping =0 for ="no" for example. The last thing I noticed while editing was that the quotes (or lack of) confused my vi syntax highlighting sometimes. I tried with AND without quotes just to be sure. The quotes are simply style, they do not seem to affect execution of the script at all (as I expected). I just wanted to make sure I wasn't overlooking a simpler difference. It is important to note that I never had the ORIGINAL bug mentioned in the description. I only had the secondary one that popped up after -r2 ebuild was released. Oddly I cannot reproduce the -r1 bug at all... not sure if anyone explained the real cause of this version madness yet. So it could be that this workaround will only work for those who could use -r1 with no problems (like me). perhaps if one of the users complaining of the original bug tried this workaround it could illustrate if the original problem reappears. I have no experience with autoconf so I do not feel confident recommending this be put in the ebuild, as I have no idea the full ramifications of changing these settings. All I can safely say is that I can confirm one more system where it works (mine). I just know the package is now installed and portage is happy (so am I). Thanks a lot for your time, and thanks to Mike for the tip on CC (I wasn't sure if that was for me or not)
If you have a look at /usr/bin/autoconf (It's a shell script), you will noticeWANT_AUTOCONF_2_5 only accepts value "1". I guess Brett still hasthe original problem (saying that libwww needs autoconf-2.5) even weput WANT_AUTOCONF="2.1" and WANT_AUTOCONF_2_1="1". I suppose those who didn't have any problem emerging -r1 and -r2 won't getbuild failure when we specify autoconf-2.13 explicitly, but the originalproblem is different from that. In Brett's system autoconf-2.13 is used (correct) but libwww source complains it needs autoconf-2.5 (incorrect?).
*** Bug 35647 has been marked as a duplicate of this bug. ***
Created attachment 22077 [details] quick way to test /usr/bin/autoconf on its reaction to different env vars again I am not sure if this is appropriate for me to submit, please let me know if not! This a a quick bash script I whipped up to test the /usr/bin/autoconf perl script. Basically we just set the version selection env vars to interesting values and then export them. Then to see which version would be executed we do autoconf version. You can easily change the values to something that makes more sense for your purpose. I just thought this could be used to end a lot of confusion about how this script will react to different input. Especially since it sounds to me like there are two different versions out there. If this script were run with interesting values on the old ac-wrapper (pre WANT_AUTOCONF) and on the new one something helpful might pop up. thanks, kelly
OK, I have just attatched a bash script I made to test out the ac-wrapper at /usr/bin/autoconf. It is a really simple script but I have learned a little bit more info with it. I didn't use any loops which makes the script longer than needed, but I wanted to make _sure_ I didn't make any mistakes when setting the variables and exporting. It has been a while since I wrote anything in bash. Below I will paste the results I got with my version of the script (apparently the new one). I took a look at the /usr/bin/autoconf script as suggested. I see that it is perl on my machine. I understand that this script has recently changed (to add the new style env var WANT_AUTOCONF). I seem to have the newer version. I had mentioned before that it didn't seem to matter if "no" or 0 was used. This is absolutely wrong. Perl considers any 0 "0" or undef false and everything else to be true. The way the script is written it just has a if(WANT_AUTOCONF_2_1) obviously 0 results in false while "no" results in true. so I would suggest that the style used in the workaround description I talked about is dangerous. I proved this in test case number 3 (see below). These variables should be set to something definately false if you want them to be false. I am sure that this is no surprise to most of you, but I was unaware. The script seems to tend to default to version 2.1 if you give it goofy values (like contradictory _2_1=1 and _2_5=1) or if you leave everything undef. below are the results of the tests that I did. sorry for the length, but the way I see it this could help sort out the original bug. This will give a good idea of what to expect from the ac_wrapper (the new version), and if compared with similar results for the old wrapper, perhaps a "confused condition" can be identified. let me know if I should test other combinations of values... I mean if you want to see a particular combo on my system. first I checked what the default would be and then I proved my theory of the "no" 0 difference, then some other values just to make sure things were working right. test results---------------------------------------------------- test1 --------------------------------------------------------- WANT_AUTOCONF_2_1 = WANT_AUTOCONF_2_5 = WANT_AUTOCONF = Autoconf version 2.13 test2 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 0 WANT_AUTOCONF_2_5 = 1 WANT_AUTOCONF = autoconf (GNU Autoconf) 2.58 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. test3 --------------------------------------------------------- WANT_AUTOCONF_2_1 = no WANT_AUTOCONF_2_5 = yes WANT_AUTOCONF = Autoconf version 2.13 test4 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 1 WANT_AUTOCONF_2_5 = 0 WANT_AUTOCONF = Autoconf version 2.13 test5 --------------------------------------------------------- WANT_AUTOCONF_2_1 = yes WANT_AUTOCONF_2_5 = no WANT_AUTOCONF = Autoconf version 2.13 test6 --------------------------------------------------------- WANT_AUTOCONF_2_1 = WANT_AUTOCONF_2_5 = WANT_AUTOCONF = 2.1 Autoconf version 2.13 test7 --------------------------------------------------------- WANT_AUTOCONF_2_1 = WANT_AUTOCONF_2_5 = WANT_AUTOCONF = 2.5 autoconf (GNU Autoconf) 2.58 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. test8 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 1 WANT_AUTOCONF_2_5 = 1 WANT_AUTOCONF = Autoconf version 2.13 test9 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 0 WANT_AUTOCONF_2_5 = 0 WANT_AUTOCONF = Autoconf version 2.13 thanks a lot guys... hope I am at least a little helpful and not just loading your inbox! ... well either way it has been interesting! :-)
Hmm, I believe that the problem may be libtool-1.5 (which I have installed on my local machine). libwww will install with libtool-1.4.3-r1 Thoughts: Although this is a current resolution for Gentoo, it isn't for me, and will possibly become a problem in the future for Gentoo. The reason I need libtool-1.5 installed is because I am trying to install bananapos (a point of sale program) if it makes any difference. With libtool-1.4.3-r1 OR libtool-1.5 (local ebuild) installed these are the results (the same for both libtool versions) test1 --------------------------------------------------------- WANT_AUTOCONF_2_1 = WANT_AUTOCONF_2_5 = WANT_AUTOCONF = Autoconf version 2.13 test2 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 0 WANT_AUTOCONF_2_5 = 1 WANT_AUTOCONF = autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. test3 --------------------------------------------------------- WANT_AUTOCONF_2_1 = no WANT_AUTOCONF_2_5 = yes WANT_AUTOCONF = Autoconf version 2.13 test4 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 1 WANT_AUTOCONF_2_5 = 0 WANT_AUTOCONF = Autoconf version 2.13 test5 --------------------------------------------------------- WANT_AUTOCONF_2_1 = yes WANT_AUTOCONF_2_5 = no WANT_AUTOCONF = Autoconf version 2.13 test6 --------------------------------------------------------- WANT_AUTOCONF_2_1 = WANT_AUTOCONF_2_5 = WANT_AUTOCONF = 2.1 Autoconf version 2.13 test7 --------------------------------------------------------- WANT_AUTOCONF_2_1 = WANT_AUTOCONF_2_5 = WANT_AUTOCONF = 2.5 Autoconf version 2.13 test8 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 1 WANT_AUTOCONF_2_5 = 1 WANT_AUTOCONF = Autoconf version 2.13 test9 --------------------------------------------------------- WANT_AUTOCONF_2_1 = 0 WANT_AUTOCONF_2_5 = 0 WANT_AUTOCONF = Autoconf version 2.13
This bug relates somewhat to: http://bugs.gentoo.org/show_bug.cgi?id=23071 I am not sure if this means that this bug report is a dupe or still relevant.
Oops, it isn't a shell script but a perl script. I thouhgt the other way around (actually WANT_AUTOCONF_2_1 accecpts any string other than "0", but I wrote it only accepts "1"). *g* Thanks for pointing out that to me. I'll try to figure out whether it is caused by libtool-1.5 (which is not part of base distribution at the moment, though).
I recieve this problem. creating Icons/Makefile creating Icons/WWW/Makefile creating Icons/32x32/Makefile creating Icons/internal/Makefile creating wwwconf.h cd . && aclocal cd . && automake --foreign --include-deps Makefile cd . && autoconf aclocal.m4:267: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/c.m4:1180: AC_C_VOLATILE is expanded from... aclocal.m4:267: the top level autom4te-2.58: /usr/bin/m4 failed with exit status: 1 make: *** [configure] Error 1 !!! ERROR: net-libs/libwww-5.4.0-r2 failed. !!! Function src_compile, Line 59, Exitcode 2 !!! (no error message) Many people speak about using autoconf 2.1x that can coexist with autoconf 2.5x and i would love to try this, although i dont have it in my portage tree. snoopy autoconf # ls ChangeLog autoconf-2.57-r1.ebuild autoconf-2.58.ebuild metadata.xml Manifest autoconf-2.57a-r1.ebuild files
Please rerun `emerge sync` and try again. Gentoo's autoconf-2.5*.ebuild contains autoconf-2.13 and either autoconf-2.13 or autoconf-2.5* is called automatically depending on situation (enviroment variables as we discussed, information from autoconf related files in source dist file, etc).
> Hmm, I believe that the problem may be libtool-1.5 I don't see libtool-1.5 in the tree ? I'm sorry, we really have enough work as it keeping up with the bugs as it is, let alone supporting home-made ebuilds and configurations. If no-one else is seeing this problem, I'm sorry but I'm going to have to resolve it invalid.
I resolved my issue (comment #21) by editing the /usr/portage/net-libs/libwww/libwww-5.4.0-r2.ebuild and changing the lines so it looks like this src_compile() { # <sys-devel/autoconf-2.57a WANT_AUTOCONF_2_5=0 # >=sys-devel/autoconf-2.58 WANT_AUTOCONF=2.1 export WANT_AUTOCONF_2_5 WANT_AUTOCONF The compile went ahead fine. :) Enjoy the weekend!! :)
Well brett's test results show us he has something seriously broken. Whether it is libtool or not I can only speculate, but this seems like a reasonable theory. The problem with the ebuild is now resolved (at LEAST for me). I just did an emerge sync and emerge libwww to make sure. -SO- Unless someone else can produce results like Brett I think Mike's suggestion in comment #23 sounds appropriate.
It's fair enough that the bug report be closed, given that it turns our that a local ebuild is the problem :-( Thanks for everybodies help anyway! If I find a solution to the problem I'll post it below for future reference.
Libtool 1.5 is in the tree now, and I'm breaking as above... running stable sparc.
Sorry, but why do you want to try libwww-5.2.0-r1 rather than libwww-5.2.0-r2? The problem is fixed in -r2 and -r2 is stable for some time. (I didn't backport the patch to -r1, so -r1 is broken in a sense) If the problem still persists with -r2, please reopen the bug.
