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

[Pekka Seppänen]

On 8/18/17 10:27 PM, Eli Zaretskii wrote:
> > Cc: Eli Zaretskii <address@hidden>
> > From: Pekka Seppänen <address@hidden>
> > Date: Fri, 18 Aug 2017 19:25:35 +0300
> >
> > 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.
> Installing Windows import libraries is commonplace in GNU projects,
> and yet I never saw those projects using WINDOWSENV or similar
> tricks.  All we need is add a variable that would be mpty on other
> systems and libgnumake-$(VERSION).dll on MS-Windows.
>
> IOW, I still don't understand why would we need to do this the way you
> suggest, if all that's missing is commands to install the import
> library.

It was just a proposal, I don't really care if that exact patch ends up 
anywhere, just the result what the patch tries to do. Maybe there's a 
more clever way to do that than what I ended up with -- anyway, should 
be doable.

Currently, the import library does not get built unless the code is 
targetted for a native Win32 host, in a sense that the host implements 
the full Win32 API, i.e. _WIN32 et. al. is defined. While (msys-)mingw 
does this (more or less), msys in this case doesn't. So one can't simply 
forcefully whack in _WIN32 macros and expect things to work on msys, as 
it's really more like cygwin -- POSIX on Win32, except that doesn't 
require an external [cygwin] DLL (and has a bit more relaxed path 
handing; the two main reasons why I prefer it).

So, if one does disambiguate these two cases; a fully compliant native 
Win32 build and a build for a native Win32 system (in this case one only 
needs the dynamic loading stuff, basically all handled by modern 
compilers under the hood), one gets two birds with one stone. So, on 
msys-mingw/mingw one would need to have __declspec(dllimport/export) AND 
win32/ objects, but on msys only the dllimport/export stuff. With the 
current way it's done by just checking for _WIN32 etc. macros (in 
intmake.h and gnumake.h) making a different between these two cases is 
not possible.

I guess what I'm trying to say here, is that all (ok, perhaps not all, 
e.g. cygwin) Win32 builds should end up with GMK_EXPORT having the 
suitable __declspec defined and -Wl,--out-implib given for the linker, 
but not necessarily having all the other Win32 stuff being pulled. I 
hope this is starting to make some sense?

-- Pekka