# cat /var/tmp/portage/app-arch/lha-114i-r7/temp/aclocal.out ***** aclocal ***** ***** PWD: /var/tmp/portage/app-arch/lha-114i-r7/work/lha-1.14i-ac20050924p1 ***** aclocal /usr/share/aclocal/zthread.m4:34: warning: underquoted definition of AM_PATH_ZTHREAD /usr/share/aclocal/zthread.m4:34: run info Automake 'Extending aclocal' /usr/share/aclocal/zthread.m4:34: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal configure.ac:6: error: 'AM_CONFIG_HEADER': this macro is obsolete. You should use the 'AC_CONFIG_HEADERS' macro instead. /usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expanded from... configure.ac:6: the top level autom4te-2.69: /usr/bin/m4 failed with exit status: 1 aclocal-1.13: error: echo failed with exit status: 1 Please note that although this package is stable and automake-1.13 is ~arch, this is still a priority fix because ~arch users are immediately affected.
I run stable, so I'm having trouble replicating this problem. It builds fine for me with stable automake (1.12.6) installed. I tried upgrading to 1.13 (which installed in a new slot), but it still builds fine for me. For a quick fix, could you not just add WANT_AUTOMAKE="1.12" to the ebuild? This is done for other stable packages in portage (such as parted, which depends on automake 1.11). So, it seems like that would be an acceptable way solve the problem of building lha. Alternatively, if you can tell me what I need to do to replicate the problem on my stable amd64 system, I'll be happy to tinker with it to see if I can get it to build with automake 1.13. I apologize if that seems like a dumb question for a proxy maintainer to ask, but I'm not particularly familiar with automake beyond the basics, so I'm not sure how portage determines which version of automake to use when building a package.
Unless things have changed in the last 3 days, in autotools.eclass (which is possible), just having automake-1.13 emerged should have made this ebuild use it. I too run stable and that's all I did to produce this error .... (edit: yes, apparently changes did occur on April 28th which makes automake-1.12 be used whenever configure.ac doesn't support the new 1.13 syntax, according to cvs log on automake.eclass) At any rate, for testing, you can force it by specifying WANT_AUTOMAKE="1.13" on the command line you use to emerge or ebuild. I expect that at some point things should still be patched to work with automake-1.13
hmm... so i just tested and this still fails for me: cd /usr/portage ebuild sys-devel/automake-wrapper/automake-wrapper-8.ebuild merge ebuild sys-devel/automake/automake-1.13.1.ebuild merge ebuild app-arch/lha/lha-114i-r7.ebuild prepare Unsure why you can't reproduce? ----- Regarding the "quick fix" , yes, WANT_AUTOMAKE="1.12" is something you could put in the ebuild. However i think that is frowned upon; also the patches in this case are quite trivial so i'm not sure if locking to automake-1.12 is really easier than patching configure.ac You should talk to flameeyes or vapier about WANT_AUTOMAKE usage; I think it's meant more for when upstreams do not intend to move beyond a particular version, than for when things happen to fail with the latest version in the tree.
(In reply to comment #3) > You should talk to flameeyes or vapier about WANT_AUTOMAKE usage; I think > it's meant more for when upstreams do not intend to move beyond a particular > version, than for when things happen to fail with the latest version in the > tree. well, this hasn't been updated for over 6 years, so we can probably safely assume they don't really plan on moving forward. :-) But yeah, I agree that it's not a "proper" solution if other options are available. Thanks for the extra info. I'll try to spend some more time with it tonight and see if I can get something working (well, broken, to be specific, and then working again).
Created attachment 346938 [details] lha-114i-r7 patch to support automake-1.13.1 huh... so I tried upgrading automake again tonight and then lha failed immediately. Don't know what the deal is. Anyway, attached is the tiny patch to the in-tree version of lha to correct this. I removed automake-1.13.1 and tested the patched version of lha against 1.12.6, and it seems to work fine there as well. Please let me know if there's anything else I can help with.
Hi @ll I tried to install the lha package today and ran into a problem that I got fixed with the attached patch by Jared B. But my error wasn't the message with AUTOMAKE_CONFIG_HEADER. I got this one x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.@am__isrc@ -I.. -DEUC -DSUPPORT_LH7 -DPROTOTYPES -O2 -pipe -c getopt_long.c getopt_long.c:67:25: fatal error: getopt_long.h: No such file or directory compilation terminated. make[2]: *** [getopt_long.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-arch/lha-114i-r7/work/lha-1.14i-ac20050924p1/src' I used the patch and it seems to work, too. http://pastebin.com/NesRa7Ab
Hey, Steffen. Can you please clarify: did applying the patch attached to this bug fix the problem for you? Sounds like it did (was just a different error you initially encountered), but was to confirm. I'm not sure what I need to do to get this pushed into the tree, but if it fixes a couple different problems then I really don't see why we shouldn't push it. If you can confirm it works for you, I'll check with a couple devs on this to see if we can close out this bug.
Hi Jared, Yes I applied your patch to the ebuild and after this the package was build successfully. BUT: I don't think that this was the result of the patch because I rebuild the package today without the patch and it build the package, too. I think its better to forget my comments on this bug, because I don't know where my error really comes from. I think that my best friends was playing on the machine (its a development and testing machine) with his other compiling crap and so this results in this and 2 other errors. This errors are gone now. So I think its better to ignore my report here and I will ask him what he has done there. Sorry for the stress that I have made for you. regards j0inty
I actually stumbled upon Steffen's compile error. Strange thing is that I did two emerge -eDN --complete-graph --with-bdeps=y --keep-going=y world, and during the first one it compiled fine, but during the second it failed. And now I can't compile it. And the pastebin-patch is gone.
Tamas, do you get that same error even with the attached patch applied to the ebuild?
Created attachment 365640 [details, diff] lha-114i-getopt_long.patch It appears that getopt_long.c is improperly including its header file, including it with: #include <getopt_long.h> rather than: #include "getopt_long.h" Under most circumstances it seems this works anyway (I guess make/gcc adds the current directory to the include path?), but I'd guess this is what's causing the issues Tamas and Steffan reported. Not sure what would trigger it, but the second option should, I'd think, work in all cases, whereas the first seems to work by chance. I'm attaching a simple patch to fix this. Please first try the original patch just to see if that has any effect here (so I know for sure one way or another). If it still fails, please try this patch as well and let me know how it works. Thanks.
Tamas, your first build was successful most probably because originally you had had automake-1.12 on your system, and during your first emerge, lha was built first (with automake-1.12), then automake-1.13 was installed. At the next re-emerge, you already had automake-1.13 so building lha failed. Guys, can we have a fix for this build failure? I mean committed AND flagged as stable. Because automake-1.13 has been flagged as stable since last September, and lha stable now does not build at all - now it should be trivial to reproduce this problem for everybody. (BTW, why isn't there a machine somewhere building the latest stable packages regularly and feeding errors into the mailboxes of the affected package maintainers? Every time I rebuild my system, there's always at least one package which is broken, even though flagged as stable.) This is the root of the problem, IMHO: my 2013 August build with automake-1.12: i686-pc-linux-gnu-gcc -O2 -march=pentium3 -mtune=core2 -fomit-frame-pointer -Wall -W -DHAVE_CONFIG_H -I. -I. -c -o getopt_long.o getopt_long.c current build automake-1.13: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.@am__isrc@ -I.. -DEUC -DSUPPORT_LH7 -DPROTOTYPES -O2 -march=pentium3 -mtune=core2 -fomit-frame-pointer -c getopt_long.c While I'm not an automake expert, I'm 100% sure that that @am__isrc@ is plain wrong there. Personally, I'd see WANT_AUTOMAKE="1.12" as a long-term solution for packages like this. Automake is deliberately not interested in keeping itself without regressions for old code, lha is not updated by the upstream to work with new automake releases, so either somebody keeps an eye on these packages and does the job not done by the upstream, or every now and then we'll get broken stable packages.
Sorry, I copied the wrong line from my old emerge output. This was the good gcc line last August: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -DEUC -DSUPPORT_LH7 -DPROTOTYPES -O2 -march=pentium3 -mtune=core2 -fomit-frame-pointer -c getopt_long.c
i am just building a new box from scratch and stumbled into the compile issue as well: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.@am__isrc@ -I.. -DEUC -DSUPPORT_LH7 -DPROTOTYPES -O2 -pipe -mtune=native -march=native -c getopt_long.c getopt_long.c:67:25: fatal error: getopt_long.h: No such file or directory -#include <getopt_long.h> +#include <getopt_long.h> makes it work - however, to properly fix it someone might also want to find out why USE_GNU isnt defined, which would make this a non issue. (the include is still wrong though)
@ian, can you look into this PR? https://github.com/gentoo/gentoo/pull/349 it's meant to fix this bug. thank you!
(In reply to Patrice Clement from comment #15) > @ian, can you look into this PR? https://github.com/gentoo/gentoo/pull/349 > it's meant to fix this bug. thank you! It's in tree. This bug can be closed.
Indeed. I merged it. Thank you for the heads up.
