On Wed, 30 Aug 2023 02:45:42 GMT, David Holmes <dhol...@openjdk.org> wrote:
> I'm sure I've said it before but there has to be a better way to handle this. > We should not have to rename perfectly well-named functions to insert a > unique prefix due to static linking conflicts. If this were C++ code rather > than C, would that fix things? Hi @dholmes-ora, thanks for looking into this PR. Yeah, we had discussed the topic in earlier similar PRs' review comments. Just to collect earlier discussions, following solutions can resolve duplicate symbol triggered static linking failure: 1. Convert affected function/variable to static whenever applicable `appendBootClassPath` in src/java.instrument/share/native/libinstrument/InvocationAdapter.c is the only caller for `normalize`. However that's shared native code. `normalize` is implemented in OS specific code, so we can't include the implementation in the same file of the caller to make `normalize` static. 2. Direct renaming, #define (or using -D) to redefine symbols for affected function/variable 3. Use namespace isolation for C++ code 4. Symbols localizing using objcopy (`--localize-symbols`) For this solution, we can partially link all `.o` for an affected native library into a single object file (`.o`) first, then run `objcopy` to localize the affected symbol(s). The resulting object file can be used for the final static linking without causing duplicate symbol issue. Partial linking/objcopy is not portable for all platforms what we should support in OpenJDK. Could you please clarify the last part of your comment? Is it related to namespace? > If this were C++ code rather than C, would that fix things? @cjmoon1's change uses direct renaming, which seems to be the most straightforward. It's possible there are other potential solutions for duplicate symbol issues with static linking, I haven't explored those yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15477#issuecomment-1699409048
