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

[Eli Zaretskii]

> 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:

  
https://sourceforge.net/projects/ezwinports/files/make-4.2.1-with-guile-w32-bin.zip/download

> 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?

> 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?

Thanks.