|
From: | Kirill Makurin |
Subject: | Re: building gettext-tools with MSVC fails |
Date: | Sat, 31 May 2025 16:39:49 +0000 |
All three warnings are not serious, however, Microsoft documentation tells that having the same symbol with different __declspec() in the same image result in less efficient code.
- Kirill Makurin
From: Bruno Haible <bruno@clisp.org>
Sent: Sunday, June 1, 2025 1:28 AM To: bug-gettext@gnu.org <bug-gettext@gnu.org>; Kirill Makurin <maiddaisuki@outlook.com> Subject: Re: building gettext-tools with MSVC fails Hi Kirill,
> I want to correct myself: check for `__CYGWIN__` config.h is needed. `_WIN32` is defined in cygwin's header files, not by the compiler. config.h is usually included as the very header first file, so `_WIN32` is likely to not be defined at this point. On Cygwin, _WIN32 is usually not defined, and the program is not supposed to #include <windows.h>. (Just a side-note, not relevant here.) > Let me summarize some things at this point. > > The incorrect definition of `DLL_VARIABLE` is responsible for variables not being properly imported from the DLLs. This result in crash at runtime. OK, let's find out how to best correct this. > (Why is there `__declspec (dllimport)`? Shouldn't it be ` __declspec (dllexport)`? I noticed linker producing a lot of LNK4197[1], LNK4217[2] and LNK4286[3] warnings) Many of these linker warnings are false alarms in the sense that the compiler or linker does the necessary corrective action automatically. I am thus only interesting in warnings that actually predict a crash. Do you know which of the warnings that you are seeing are actually worrisome? > (Is there any other platform where libtool defines `DLL_EXPORT`? If not, check for `_WIN32` and `__CYGWIN__` in config.h.in for libraries can be omitted. But these are just some thoughts, I don't say we should do it.) I prefer to be clear about the platforms because, when I make a change or when there is a bug to investigate, I want to know on which platforms to test. (If I were to be so confused that I test something on a platform where it has no effect, it would be a huge waste of time.) > For libraries, existing conditions in `config.h.in` work properly: > > ``` > #if (defined _WIN32 || defined __CYGWIN__) && defined DLL_EXPORT && !defined IN_RELOCWRAPPER > # define DLL_VARIABLE __declspec (dllimport) > #else > # define DLL_VARIABLE > #endif > ``` > > > > However, this condition does not work when building applications. Maybe we can understand things better by looking at the relevant commits. 1) The first commit https://gitweb.git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=8752367c1cbd1a5c231e423dbd1c186ea1c67841 seems to be correct, do you agree? 2) In the second commit https://gitweb.git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=8e914861708ed459a2ae8157eb60d89375ab46cd the first part is correct as well, because in gettext-runtime, the gnulib modules (that use DLL_VARIABLE) are compiled without libtool, in other words, there is no library like libgettextlib there. But the problem is with the second part. While the Makefile in gettext-tools/gnulib-lib is running, that is, while building libgettextlib, the expansion of DLL_VARIABLE should be __declspec (dllexport) not __declspec (dllimport) right? Whereas while the Makefile in gettext-tools/src is running, that is, while building libgettextsrc or the programs, we need two different macros instead of one: - the DLL_VARIABLE occurrences in gnulib-lib/*.h need to expand to __declspec (dllimport) - but the DLL_VARIABLE occurrences in src/*.h need to expand to __declspec (dllexport) Would you agree with that? > I think we need to define a macro which tells us that we are linking against shared libraries. And we need different macros for different shared libraries. Bruno |
[Prev in Thread] | Current Thread | [Next in Thread] |