An earlier posting, back some years ago, noticed the problem with
AC_CHECK_HEADERS(appkit/appkit.h appkit.h) in configure.ac on Mac OS X.
Shortly, the WWW-library checks for appkit.h or appkit/appkit.h and
wrongly include this header on Mac OS X in wwwsys.h. The bootstrap
procedure worked back some years ago for me, but GCC's ability to
include header files case insensitive (<appkit/appkit.h> <=>
<AppKit/AppKit.h>) may be the reason for current failure. (?) I'm using
If it should be left, I suggest we introduce a NEXTSTEP host-switch,
like the MINGW32 and the CYGWIN. But if it shouldn't be left, I suggest
we uncomment the line with a short comment. There is no need for this
header on Mac OS X.
I would greatfully apprecate hints how to fix this, without relaying on
changing configure.ac all the time.
> From: Jake Hamby <[hidden email]>
> Date: Fri, 19 Oct 2001 14:31:06 -0700
> To: [hidden email] > Message-Id: <[hidden email]>
> Just a quick note regarding a bug I noticed with Libwww on Mac OS X.
> There is a configure check for the presence of <appkit/appkit.h> or
> <appkit.h> (the NeXT Application Kit). On OS X, configure sets
> HAVE_APPKIT_APPKIT_H and <appkit/appkit.h> is then included by
> While this unnecessary (as far as I can tell) #include doesn't hurt the
> build of Libwww itself, it causes problems with C++ programs which use
> libwww, as the C++ compiler can't handle the Objective-C syntax in the
> included AppKit headers. My suggestion would be to remove the
> HAVE_APPKIT checks completely, as they appear to serve no useful value,
> and introduce an unnecessary dependency on an unused library. The only
> possibility I can think of for their presence is that maybe there was
> old version of NEXTSTEP that required the AppKit to be included to pick
> up some functionality that would normally be in a more standard header?
Re: HAVE_APPKIT_H check inappropriate for Mac OS X
2006-03-12 kl. 15.48 skrev Vic Bancroft:
> Roger Persson wrote:
>> Shortly, the WWW-library checks for appkit.h or appkit/appkit.h and
>> wrongly include this header on Mac OS X in wwwsys.h. The bootstrap
>> procedure worked back some years ago for me, but GCC's ability to
>> include header files case insensitive (<appkit/appkit.h> <=>
>> <AppKit/AppKit.h>) may be the reason for current failure. (?) I'm
>> using gcc 4.0.1.
> Does there exist a current operating system version of these headers
> all lowercase ?
No, it seems to be the compiler that ignore lower and upper case path
names. This is the error message
95: error: stray '@' in program
In file included from
Note that the error is an effect of illegal Objective-C statements in
>> I would greatfully apprecate hints how to fix this, without relaying
>> on changing configure.ac all the time.
> Does your diff look like this ?
> $ cvs diff configure.ac
> Index: configure.ac
> RCS file: /sources/public/libwww/configure.ac,v
> retrieving revision 1.6
> diff -r1.6 configure.ac
> < AC_CHECK_HEADERS(appkit/appkit.h appkit.h)
> > AC_CHECK_HEADERS(AppKit/AppKit.h Appkit.h)
Yes, the lowercase check. But I can't find reasons to include this on
Mac OS X (or any old NexStep system).
This is because I searched for function calls NS...(...), i.e the
common prefix for appkit.h functions, but there isn't even a match.
Typcial cases where I expected to find such calls would be HTUser.c,
HTInet.c, etc., i.e. for quering user name, home path, etc. But BSD
routines are used instead.
If there are no need for this header in the library, is there any need
for this check then?
Removing this check would reduce configuring time.