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

[Jannick]

On Mon, 23 Dec 2019 07:54:44 -0700, address@hidden wrote:
> Eli Zaretskii <address@hidden> wrote:
>
> > > From: address@hidden
> > > Date: Mon, 23 Dec 2019 00:41:37 -0700
> > > Cc: address@hidden, address@hidden

> > > I think Janick is using MSYS2, which is essentially Cygwin.

Yep.

> > I think he is using MSYS2 to build MinGW Gawk.

Nope, if MinGW Gawk implies using the /pc stuff and MINGW32 or MINGW64.  :)
This would be a cross-compile.  Again, I have not had the time to really
look into the /pc directory until now. Maybe later.

> Janick, can you please clarify what you're doing?

Sure - I am trying to build gawk using MSYS with autoconf to the end to make
use of some gawk extensions provided by gawkextlib.  A bunch of gawkextlib
tests simply failed because of the raised issue.  I needed to go back to the
MSYS2 version of gawk to figure out why these tests failed.

$ gcc --version
gcc (GCC) 9.1.0
$ gcc -dumpmachine
x86_64-pc-msys
$ autoconf --version
autoconf (GNU Autoconf) 2.69

Regarding the msys2 support I looked into the gawk and gnulib repositories:
In November it was shortly in, then quickly out again, in both gawk and
gnulib.  The gnulib devels rather prefer to wait to add the msys2 support
until this will have happened upstream in libtool.  Until then, Arnold, the
'evil hackery' around GAWKLIBEXT in the main configure.ac stands I guess.

BTW: In addition to the comment close to the hackery, the m4-macro
LT_SYS_MODULE_EXT defines the cpp-macro LT_MODULE_EXT using $shrext_cmds
which effectively is what GAWKLIBEXT is today.  Maybe using
LT_SYS_MODULE_EXT once libtool/gnulib is made fit for msys2?

> Thanks!
>
> Arnold

HTH.

Many thanks to both of you,
J.