> Date: Fri, 18 Aug 2017 16:15:15 +0300 > From: Pekka Seppänen <[email protected]> > > 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. _______________________________________________ Bug-make mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-make
