bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin


From: Bruno Haible
Subject: Re: [PATCH] Do not decorate symbols as dllexport on Cygwin
Date: Sun, 05 Feb 2023 21:41:21 +0100

Hi Corinna,

Thanks for the heads-up and patch.

> Note that dllimport/dllexport decorations are not at all required on
> Cygwin for quite some time.

Is this true in all circumstances? I thought that when --disable-auto-import
is in use AND the shared library wants to export variables, dllimport
and dllexport decorations are necessary.

> On Cygwin --export-all-symbols is default.  However, if just a single
> symbol is decorated with dllexport, ld switches to exporting only these
> symbols.
> ...
> An example of that is current recode.  Building this package with
> --enable-shared is broken, unless one adds -Wl,--export-all-symbols to
> the link stage command line explicitely, because of the decorated
> gl_get_setlocale_null_lock variable.

So, there are three types of packages:
  (A) Those that use --disable-auto-import (e.g. [1][2]) and provide an
      explicit list of exports for their shared libraries.
  (B) Those that don't use --disable-auto-import but want to limit
      the exposed symbols for other reasons (e.g. namespace cleanliness).
      Such as those that use the libtool options '-export-symbols' or
      '-export-symbols-regex'.
  (C) Those like 'recode', which want all symbols to be exported (e.g.
      if namespace cleanliness is not an issue for them).

For packages of type (A) or (B), the symbol gl_get_setlocale_null_lock
*MUST* be exported, otherwise there may be different get_setlocale_null_lock
functions accessed by different code, which will destroy the purpose of this
function, i.e. open the door to potential crashes due to use of setlocale().

For packages of type (C), the symbol gl_get_setlocale_null_lock *MUST NOT*
be exported, otherwise all other symbols will not be exported.

AFAIU, your patch fixes packages of type (C), while at the same time breaking
packages of type (A) or (B).

Is there an easy way to distinguish packages of type (C) from those of type
(A), (B)?

Another option — since we are talking about a single symbol and a single
platform — would be if the locking for setlocale_null were not necessary
on Cygwin in the first place. I determined that it is necessary by running
the unit test gnulib/tests/test-setlocale_null-mt-all.c [3] on Cygwin:
without the lock, it crashed within less than 1 second. Could the
implementation of setlocale() in Cygwin be changed in such a way that this
test does not crash? Then the lock would be necessary.

Bruno

[1] 
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/woe32dll/export.h;hb=HEAD
[2] https://haible.de/bruno/woe32dll.html
[3] 
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-setlocale_null-mt-all.c;hb=HEAD






reply via email to

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