bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org, Corinna Vinschen <vinschen@redhat.com>
Subject: Re: [PATCH] Do not decorate symbols as dllexport on Cygwin
Date: Sun, 05 Feb 2023 21:41:21 +0100	[thread overview]
Message-ID: <2995619.l0kZKy6ypc@nimes> (raw)
In-Reply-To: <20230205194344.269174-1-vinschen@redhat.com>

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	other threads:[~2023-02-05 20:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-05 19:43 [PATCH] Do not decorate symbols as dllexport on Cygwin Corinna Vinschen
2023-02-05 20:41 ` Bruno Haible [this message]
2023-02-05 20:48   ` Bruno Haible
2023-02-05 21:22   ` Corinna Vinschen
2023-02-06 15:08     ` Corinna Vinschen
2023-02-06 16:36       ` Bruno Haible
2023-02-06 17:37       ` Bruno Haible
2023-02-06 20:04         ` Corinna Vinschen
2023-02-06 20:38           ` Bruno Haible
2023-02-06 20:43             ` Corinna Vinschen
2023-02-06 20:50             ` Reuben Thomas
2023-02-07 13:22               ` Corinna Vinschen
2023-02-07 15:22                 ` Corinna Vinschen
2023-02-10 14:11                   ` Reuben Thomas
2023-02-10 14:21                     ` Bruno Haible
2023-02-11 11:36                       ` Reuben Thomas
2023-02-11 12:06                         ` Corinna Vinschen
2023-02-11 12:29                           ` Reuben Thomas
2023-02-11 12:40                             ` Corinna Vinschen
2023-02-17  9:30                               ` Reuben Thomas
2023-02-17  9:58                                 ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2995619.l0kZKy6ypc@nimes \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=vinschen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).