[ntp:hackers] Re: [Bug 659] libopts will not build on Windows

Bruce Korb bruce.korb at gmail.com
Fri Jul 28 15:49:35 UTC 2006

Hi Danny,

Danny Mayer wrote:
>>What I really need is:
>>but I do usually type that out as:
>> #ifdef HAVE_CONFIG_H
>>since the configure script inserts that for me automatically.
>>HAVE_CONFIG_H should *NOT* be defined for vanilla Windows.
> That's never true. Too much code would break if that were true.

Whose code?  In the autotools build world, "HAVE_CONFIG_H"
means precisely that the file "config.h" is available and
contains the results of the probes in the project's configure
script.  If you did not run configure itself, that is okay
but it still must contain all the correct answers that would
normally be computed by the configure script.  If you are saying
that it is okay to use a generic "config.h" that you have lying
around for the platform, then you are wrong.  "config.h" is
_always_ project specific.

>>If I blew it, I'll fix it.  "windows-config.h" should be included IFF:
>> #if defined(_WIN32) && ! defined(HAVE_CONFIG_H)
> No, that's not true.

Yes, this is true.  If you have hand created a header specifically
named "config.h" and gotten it in place and it answers all the
project specific probes computed via the configure script, then
(and only then) may you put ``-DHAVE_CONFIG_H'' on the command line.
I do not believe you have done that.  Do not specify that.

> See above. You need to decide whether the windows
> includes are in config.h or your windows-config.h so I can decide where
> to put all of the changes needed to just build libopts.c. Right now my
> preference is to put the specific stuff into windows-config.h so I don't
> clutter up the config.h file with a lot of extra stuff just for libopts.

If you specify -DHAVE_CONFIG_H for libopts compilation, then you
are claiming that you specifically have a file named "config.h"
that answers libopts' needs.  Do not do that.  Here are your choices:

1.  Include libopts probe results in your hand crafted config.h
     and specify -DHAVE_CONFIG_H on the command line

2.  Include the necessary environment information in windows-config.h
     and *NOT* specify -DHAVE_CONFIG_H on the command line

3.  Set up a MingW (sp??) Windows build environment and actually run
     the configure script for NTP.  It will automatically produce a
     "config.h" header.  The Makefile-s will also build with
     -DHAVE_CONFIG_H on the command line.

If libopts is compiled with -DHAVE_CONFIG_H and libopts probe results
are not in that header, the build will break.  I do not understand
why a different result would be expected.

>>If "HAVE_CONFIG_H" has been defined and "_WIN32" is defined, then
>>I would expect to be running under CygWin.

(or MingW).

> That's definitely not true and will never be true. If you are looking
> for Cywin use the __CYGWIN__ to check for that and nothing else.

__CYGWIN is not defined for MingW.  It is specific to one particular
POSIX-for-Windows compatibility environment.  I am looking for the
results of the configure script probing.  -DHAVE_CONFIG_H says
*specifically* that it is available.  -UHAVE_CONFIG_H says the
results are not available.  In that case, I am willing to use
the indicator ``#ifdef _WIN32'' to say I should include "windows-config.h".

> The functions defined in snprintf.c cannot be used on Windows as they
> already have their own functions in the library. Because of the way
> these functions are defined on Windows you can never redefine them in
> this way.

snprintf should only be pulled in if the HAVE_SNPRINTF macro is not
defined.  "config.h" or "windows-config.h" should have it defined.
The probe AC_CHECK_FUNCS(snprintf) should successfully probe for it
on a CygWin/MingW platform.

Cheers - Bruce

More information about the hackers mailing list