Re: [PATCH] dynamic object-file support for *-*-mingw32 and *-*-msys

[Pekka Seppänen]

On 8/18/17 5:09 PM, Eli Zaretskii wrote:
> > Date: Fri, 18 Aug 2017 16:15:15 +0300
> > From: Pekka Seppänen <address@hidden>
> >
> > It seems that the dynamic object loading via `load' seems to be a bit
> > incomplete on Windows (~ish) platforms. It has (and hoping to say, was)
> > mostly to do with the build envinronment, so I decided to fix that.
> >
> >   From what I see, excluding cygwin, the dominant (and up-to-date) POSIX
> > alike envinroments for Windows are msys and mingw. While they both
> > execute natively without any external emulation layer, the first doesn't
> > expose Win32 API by default while the latter does. Currently dynamic
> > object loading expects Win32 build to be compiled via build_win32.bat --
> > which neither of the systems do. They both use automake/autoconf, so for
> > msys no gmk_* functions get exported as it's not detected (as it
> > shouldn't be) as a Win32 platform. For mingw gmk_* functions are
> > dllexported, but the resulting libgnumake-1.dll.a import library does
> > not get installed, so the symbols are unavailable unless you extract
> > those from the compiled binary. In other words, while possibly doable,
> > will get ugly right from the very first step.
> Building GNU Make natively on MS-Windows is supported via the
> build_win32.bat script.  We don't currently officially support such a
> build via autotools for 2 reasons:
>
>   . historically, no one has ever submitted patches to support a MinGW
>     build by running autotools in the MSYS envinroment
>   . building Make is a bootstrap-like operation, because the build
>     process requires running Make, so build_win32.bat is needed anyway,
>     even if we at some point add support for building with autotools
>
> The build_win32.bat script doesn't support the installation of the
> produced binaries and the related auxiliary files (such as
> documentation, for example) in the "make install" style.  That is the
> only way I can understand your saying above that "the resulting
> libgnumake-1.dll.a import library does not get installed" -- it
> doesn't get installed because _nothing_ gets installed.  The user is
> supposed to install everything by hand.  You can see what such an
> installation should look like here:

Oh, by no means I'm saying that build_win32.bat would be or is useless. 
No, no.

Yes, I understand that it's not an autotools drop-in replacement, so 
each and every distribution using it must copy all the requisite binary 
files to whatever location they will. And they actually do, yes. 
However, at least with msys necessary libraries and devel packages for 
building the source using autotools already exist, so there's no need to 
boostrap everything from the ground up using that somewhat crude route 
each and every time. Thus, at least in this case msys and msys-mingw64 
(mingw64 style build, but distributed under msys) packages (that end up 
distributed) are built via the autotools route, not by build_win32.bat.

So, current binary packages for GNU Make on msys lack libgnumake-1.dll.a 
as, like you said, no one has ever submitted any patches regarding this 
matter. One could possibly overcome this by manually copying 
libgnumake-1.dll.a after autotools have completed its job, but I think 
that's a major oversight given that it is very well able to install 
files. Moreover, while this would "fix" the problem for msys-mingw64, it 
wouldn't fix it for standalone msys and it wouldn't definitely fix it 
for anyone else not using the bootstrap method.

> > My proposal is to split WINDOWSENV to WINDOWSENV and WINDOWSIMPORTLIB.
> Sorry, I don't think I understood from your description what is the
> purpose of this proposal.  Can you please elaborate?  What
> functionality will Make support after your changes that it doesn't
> support now?

For autotools there's nothing that would copy the libgnumake-1.dll.a to 
libdir, nor will such file ever be produced unless --build=host matches 
*-*-mingw32, i.e. WINDOWSENV is set, which in case of a native msys 
build won't happen. As the OS API is different between msys (POSIX) and 
mingw/msys-mingw (Win32), one can't compile both msys and msys-mingw 
packages using the same sources, as in what OS code gets picked up. So, 
pretty much the only shared thing between msys and msys-mingw is that 
they both are able to produce the import library, and it is needed if 
you'd like to link your plugin against the gmk_* functions.

> > The first is the full Win32 treatment, as currently done. The latter is,
> > like the name suggest, Win32-compatible import library creation. Mingw32
> > systems get both WINDOWSENV (so it uses Win32 API) and WINDOWSIMPORTLIB,
> > while msys only sees WINDOWSIMPORTLIB (and uses POSIX API). As msys
> > compiler will not set _WIN32 etc. defines, a new macro value is needed
> > so that user may request dllimport when including gnumake.h. Also, there
> > were no extern "C" guards so I went ahead and added those, too.
> Does this mean you want GNU Make to support the MSYS build (which is
> different from the MinGW build)?  IOW, do you want to be able to build
> an MSYS version of Make, which depends on the MSYS DLL?

Pretty much yes, actually spot on. Also, the mingw/msys-mingw build 
would benefit from this, too, as current Makefile.am configuration will 
not install the libgnumake-1.dll.a anywhere.

To summarize, in the future, I'd like to be able to build a shared DLL 
library for GNU Make (on msys, on msys-mingw, on mingw, or whatever 
POSIX alike layer runs on a native Windows). It is techinically 
possible, but the only thing currently lacking is that either a) 
libgnumake-1.dll.a is not built, b) nor it doesn't end up in the binary 
distribution, unless the binary distributer happens to manually 
copy/install that file.

Hope this elaborates the situation a bit more.

-- Pekka