[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 23:19:08 +0300
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2

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

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

reply via email to

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