Summary: | app-arch/lha fails to build with automake 1.12 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Jared B. <nitro> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | proxy-maint, ssuominen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/app-arch%3Alha-114i-r7%3A20120623-114351.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 421465 |
Description
Diego Elio Pettenò (RETIRED)
2012-06-23 11:47:09 UTC
Standard solution would apply: remove the macro, pass -DPROTOTYPES to cppflags... But it seems that it's used only in src/prototypes.h, so you could simply patch that file. @flameeyes * Include in your bugreport the contents of: * * /tmp/portage/app-arch/lha-114i-r7/temp/aclocal.out (In reply to comment #2) > @flameeyes > > * Include in your bugreport the contents of: > * > * /tmp/portage/app-arch/lha-114i-r7/temp/aclocal.out It's already included - the files are cat-ed into a single one. Uh, Rafal, AM_C_PROTOTYPES is not even defining PROTOTYPES, AC_C_PROTOTYPES is (which is probably what one wants to call at that point, it's not declared yet afaict). *it's not declared deprecated yet. (In reply to comment #5) > *it's not declared deprecated yet. sort of wrong - from automake 1.11 (/usr/share/automake-1.11/protos.m4) AC_DEFUN([AM_C_PROTOTYPES], [AC_REQUIRE([AC_C_PROTOTYPES]) AC_DIAGNOSE([obsolete], [$0: automatic de-ANSI-fication support is deprecated]) if test "$ac_cv_prog_cc_stdc" != no; then U= ANSI2KNR= else U=_ ANSI2KNR=./ansi2knr fi # Ensure some checks needed by ansi2knr itself. AC_REQUIRE([AC_HEADER_STDC]) AC_CHECK_HEADERS([string.h]) AC_SUBST([U])dnl AC_SUBST([ANSI2KNR])dnl _AM_SUBST_NOTMAKE([ANSI2KNR])dnl ]) in 1.12 it's just: AC_DEFUN([AM_C_PROTOTYPES], [AC_FATAL([automatic de-ANSI-fication support has been removed])]) obviously it does define PROTOTYPES, due to AC_REQUIRE. It's not a particular macro, that's deprecated, it's whole de-ANSI-fication. Repeating myself (with the correction applied): Uh, Rafal, AM_C_PROTOTYPES is not even defining PROTOTYPES, AC_C_PROTOTYPES is (which is probably what one wants to call at that point, it's not declared deprecated yet afaict). Read me again, carefully. AM_C_PROTOTYPES (AM!) is deprecated in 1.11 and gone in 1.12. AC_C_PROTOTYPES (AC!) is not deprecated, it's provided by autoconf (not automake) and defines PROTOTYPES. See http://www.flameeyes.eu/autotools-mythbuster/forwardporting/automake.html as well. Please don't just add -DPROTOTYPES magically, as we'll lose track of it altogether otherwise. While *technically* not deprecated, 'info autoconf' on AC_C_PROTOTYPES: -- Macro: AC_C_PROTOTYPES: ... This macro is obsolescent, as current C compilers support prototypes. New programs need not use this macro. so while I'm not autoconf upstream, so can't say for sure, most likely the only reason this macro wasn't already deprecated was... automake. Obsolete is different from deprecated — unfortunately. My only point though is I'd prefer replacing the AM macro with the AC macro instead of using -DPROTOTYPES — if you want to get rid of the macro altogether, then simply remove the _need_ for -DPROTOTYPE at once (who the hell still uses ANSI C?!). As for your page - thanks for doing the work, but in this particular case you're digging too deep into implementation. The only *public* effect of AM_C_PROTOTYPES (besides those from AC_C_PROTOTYPES) was setting ANSI2KNR vars/rules. The other two were private and only for benefit of ansi2knr.c. (btw, you've made a slight typo in the new block) I know that was the intention of automake. On the other hand I know that half the time things are done as side effects, somebody _is_ relying on said side effects. I've seen more than once a macro being slimmed down causing miscompilation because one test it was doing was relied upon, but never made explicit. ...but now, that I've read that paragraph again, I see that you've got the order wrong - it's ANSI C, that was the *new* standard, K&R was the initial C implementation and ansi2knr from the very start was provided for backward compatibility. Sigh that one I always get wrong (used to think about _ISO_ C as the current one). But we're swamping Jared with information he doesn't care about, can we just stick with: - don't just define -DPROTOTYPES; - if you're in touch with lha upstream, make them drop the whole reliance on PROTOTYPES define; - make sure that the package is not relying on other macros called by AM_C_PROTOTYPES (namely the AC_HEADER_STDC and AC_CHECK_HEADERS([string.h]); - replace AM_C_PROTOTYPES with AC_C_PROTOTYPES. :lol: "if you're in touch with lha upstream"... the one, that hasn't released a thing since 2006/10/16 (even if there was a bit work done in the repo http://sourceforge.jp/projects/lha/scm/git/lha/) ? Also, I neither speak nor read Japanese (can barely work with rikai.com guesses). Besides, AFAICT, the upstream simply ran autoscan at some point back in 2001. I really don't care to know the details of projects I don't maintain. Whether there is an upstream or not it's of very little interest to me. If needed fork it, or whatever. Just do it properly and not with a partial hack as you suggested to begin with. Diego, I suppose there are no direct replacement for AM_C_PROTOTYPES, right? People have been telling me to just drop it and append -DPROTOTYPES to CPPFLAGS for #ifdef's. Fixed in tree now. Let me know if you know better fix for this. ...anyway, my initial comment was aimed at this particular package. AC_HEADER_STDC is already called in configure.ac (and that macro already checks for string.h), so AFAICT, in this particular case, appending -DPROTOTYPES should be a safe solution. (In reply to comment #16) > I suppose there are no direct replacement for AM_C_PROTOTYPES, right? > There is no direct replacement, cause unless the upstream was relying on side effects of that macro, its only effect outside automake was "-DPROTOTYPES -D__PROTOTYPES", with the second definition used rarely ever. Then just say you checked it already next time — it didn't appear the case (you said "standard solution", but the only way you have a standard solution is using an idempotent replacement). uh hu, guys, I completely missed this bug already had a discussion about it (expected a boilerplate Comment #0 and that's it) and of course I've checked all the C files for *PROTOTYPE*... OK then :P Well, I said "standard solution" cause it seems to me that *most* of AC_C_PROTOTYPES users didn't really know why did they use it in the first place, so *usually* "-DPROTOTYPES" does suffice. WILL YOU STOP REOPENING THE BUG? Samuli fixed it. (In reply to comment #22) > WILL YOU STOP REOPENING THE BUG? Samuli fixed it. sorry, accident, most of the times, that bugzilla warning is a false positive, so I tend to ignore it |