bug-gettext
[Top][All Lists]
Advanced

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

Re: building gettext-tools with MSVC fails


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




reply via email to

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