Re: [Autogen-users] autogen 5.8.7 / Mac OS X.4.8 build problem

[Bruce Korb]

Hi Ralf,

Ralf Wildenhues wrote:
> What is unclear about the following, quoting from
> http://www.gnu.org/software/autoconf/manual/html_node/Present-But-Cannot-Be-Compiled.html
> ?
>
> | The proper way the handle this case is using the fourth argument
> | (see Generic Headers):
> |
> | $ cat configure.ac
> | AC_INIT([Example], [1.0], address@hidden)
> | AC_CHECK_HEADERS([number.h pi.h], [], [],
> | [[#if HAVE_NUMBER_H
> | # include <number.h>
> | #endif
> | ]])
>
>> I am going to take a wild guess that
>> I replace this line from snprintfv.m4:
>>
>> AC_CHECK_HEADER(wchar.h)
>>
>> with this:
>>
>> AC_CHECK_HEADER([wchar.h], [], [],
>> [[#if HAVE_WCHAR_H
>> # include <wchar.h>
>> #endif
>> ]])
>
> That wouldn't make any sense. A prerequisite header would typically be
> a different one.
That is (almost) exactly the example from the Present-But-Cannot-Be-Compiled
chapter, modulo s/number/wchar/. I agree that it makes no sense. That's
why I forwarded the issue to the autoconf list. If you were meaning to
show an example of "pi.h" needing, but not self-including, "number.h"
and how to get around it, you need some more exposition on that.
It _is_ unclear what you are getting at. Perhaps just clarify by
breaking it into two "AC_CHECK_HEADER()" invocations. Not only do I not
know the nitty-gritty implementation details of AC_CHECK_HEADERS(),
I also have a strong desire for not learning them. :) Understanding
how your fourth argument works there means knowing that every listed
header is completely handled before starting on the next listed header.
If you were to emit all the #define HAVE_WHATEVER_H at the end, then
your example here breaks. (I didn't want to figure that out.)
>> Since reasonably modern system headers should be self-sufficient
>> (you should 'a been there in the seventies and eighties!!),
> Welcome back to the seventies and eighties then, I guess.
No. Back then, very few headers were self sufficient and programmers
were expected to learn the proper order and dependencies of system
header files. Part of the programmer hazing rituals, I guess.

So, with Tomaz' input, I now know the fix. Snprintfv needs some more
configury magic for wint_t. It presumes that HAVE_WCHAR_H implies that
any system defined wint_t is visible if you #include <wchar.h>.
So, OS/X is "special" here. I suggest adding a specialized
AC_CHECK_WINT_T macro that deals with this Darwinism and I'll hack up
my configury magic to ensure that <ctype.h> gets rolled into
the required headers before the existence of wint_t is tried.

> I *then* looked at the DarwinPorts portfile, which runs the standard
> "./configure ; make" but before doing so, defines CPPFLAGS to be
> "-D_WINT_T". This gets around the "lipopts.c" compile
It would be "really nice" if folks who hack around such issues would send
me a note. I could have fixed this as long ago as someone first discovered
this issue. :( Are there any other mods in the "portfile", Tomaz?

Thanks Ralf & Tomaz for your feedback. Regards, Bruce