RFR: 8328614: hsdis: dlsym can't find decode symbol [v2]

[Magnus Ihse Bursie]

On Sat, 23 Mar 2024 09:42:33 GMT, Andrew Haley <aph at 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