Re: build on Windows: shared object extension not set to 'dll' (to 'so' instead)

[Eli Zaretskii]

> From: "Jannick" <address@hidden>
> Date: Sun, 22 Dec 2019 17:01:45 +0100
> Cc: address@hidden
> 
> For your review attached a tiny patch designed to be as minimal as possible.
> The windows platform iff EXEEXT='.exe' which, I believe, is safe.  Only an
> .exe calls a .dll.

Not really safe, IMO, since the DJGPP (a.k.a. "MSDOS") port of Gawk
also uses .exe, but doesn't use .dll for dynamically loaded libraries.

> (NB: I did not choose one of the other options I could currently think of:
> 1/ using $os which currently fails for MSVC (so less reliable) or 2/
> checking if one of the cpp macros __CYGWIN__, _WIN32 or _MSC_VER provided by
> the compiler is defined (OK for now until another Windows compiler family
> might enter the scene, but who knows)).

AFAIK, Gawk no longer supports building with MSVC.

> > (Cygwin uses configure; MinGW uses the build stuff in the pc/ directory.)
> 
> I have not looked into the pc/ directory yet, since I rather put autoconf to
> work.  I just realized that MinGW32/64 the autoconf route fails (make/gcc
> complains about not finding a header file).  With a little bit of more time
> I could look into that (just let me know if interested, then I could try to
> report back with more insights or patches).
> 
> But right now I am more after getting gawkextlib up and running using the
> autoconf machinery on Windows/Cygwin.  BTW, this is how I bumped into the
> issue of this thread.

If you prefer to build using the autotools, then you are on your own,
because the "official" MinGW build of Gawk doesn't support that.
Please also note that without using the pc/ stuff, you will be unable
to run the test suite without a lot of unexplained failures, so
verifying your build will be problematic at best.

Does gawkextlib really require to build Gawk with autotools?  Why and
how does it do that?