On Sat, 23 Mar 2024 09:42:33 GMT, Andrew Haley <a...@openjdk.org> wrote:
> And neither should we compile or link it with "-fvisibility=hidden". That is
> the root of this problem.
If you suggest that we should not compile hsdis with hidden visibility, I
disagree. I have been working hard on unifying build of native libraries across
the entire product, to fix holes where we have not used a consistent way of
compiling and/or linking. There is no reason to tread hsdis differently. If I
restore using hidden visibility as an option that all native libraries, except
hsdis, must opt in to, then we are just back to square one, and suddenly
someone will forget about it. Instead, now we set -fvisibility=hidden in
configure so nobody can forget about it.
That was the more general argument for alinging compilation and linking flags
and behavior across the product. Regarding the symbol visibility more
specifically, there is also the question of consistency across platforms. On
Windows, the behavior corresponding to "-fvisibility=hidden" is always turned
on. Functions can only be exported if they are explicitly annotated in the
source code (or specified otherwise to the linker). So we are in any case
forced to export functions on Windows.
Let's have a look at this patch. Currently we have code like:
#ifdef _WIN32
__declspec(dllexport)
#endif
Robbin proposes to change this to
#if defined(_WIN32)
__declspec(dllexport)
#elif defined(_GNU_SOURCE)
__attribute__ ((visibility ("default")))
#endif
My counter-proposal was to replace it with just `JNIEXPORT`. Surely you can't
say that is a worse solution?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18400#issuecomment-2017526903
