[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pekka Seppänen
Subject: Re: [PATCH] dynamic object-file support for *-*-mingw32 and *-*-msys
Date: Fri, 18 Aug 2017 19:25:35 +0300
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]