| From: Akim Demaille <[EMAIL PROTECTED]>
| Date: 27 Jul 2000 11:31:41 +0200
|
| Either we trace where they are needed and move _ALL_SOURCE into an
| AC_CHECK_FUNC or so, or we just systematically invoke them, as soon
| as a C compiler is wanted.
|
| It's more reasonable to move them into the C compiler check. The
| problem here is to identify the right C compiler options to use when
| plain $CC is pedantic for some reason. The issue here is broader than
| just AC_CHECK_FUNC; feature-test macros can also make macros or enums
| visible, for example.
OK, I prepare a patch along these lines.
| However, GNU applications tend to avoid pickiness options like -ansi;
| they just causes too many problems. So there shouldn't be any reason
| for them to define _GNU_SOURCE in theory. Apparently, though, in
| practice there are sometimes incomptabilities between gcc and glibc
| (e.g. the current versioning problem relating to the upgrade to C99),
| which cause the library to mistakenly think the compiler is being
| operated pedantically. It makes sense to define _GNU_SOURCE to work
| around these glitches.
OK, thanks!
| The simplest workaround for this problem is for autoconf to do the
| equivalent of the following before compiling any C programs:
|
| AC_DEFINE(_GNU_SOURCE, 1,
| [Define unconditionally for setting a GNU environment.])
C and C++ or just C?
| Perhaps AC_AIX could be done automatically as well. I don't offhand
| see any reason to omit it. Similarly for _HPUX_SOURCE -- but doesn't
| the latest autoconf already do HPUX_SOURCE automatically?
Only with AC_PROG_CC_STDC.
| At any
| rate, I think the above macros should be defined by default as needed,
| though perhaps there should be a way for configure.in to disable this
| (for weird maintainers who actually prefer their ports to use picky
| and limited compilation environments :-).
Well, we'll keep them in separate macros which people might define to
empty if they wish, but I'd rather not document such thing: it's just
a provision in the case something goes wrong, but I don't think we'll
need that.
| - Macro: AC_PROG_GCC_TRADITIONAL
|
| I'd like to have opinions on this one: should it be swallowed in an
| AC_CHECK_FUNC or so? Should it be systematically run? Should we
| deprecate this macro?
|
| I would deprecate it. First, it's way obsolete -- the systems it
| addresses were obsolescent even in 1992 and have died off since then.
| Second, it didn't really solve the problem in general. In practice,
| obsolete headers cause problems that adding -traditional doesn't fix.
| Perhaps the currently most-common problem with obsolete headers is
| people using GCC 2.7.2.x on Solaris 2.6 or later -- and these headers
| are all ANSI C.
Thanks Paul! What I particularly enjoy with your answers is that I
just have to cut and paste, and voilą! a nice addition to the
documentation :)
Akim
