On Mon, 29 Jan 2024 09:42:20 GMT, Andrew Haley <a...@openjdk.org> wrote:
> > Maybe we could live with symbol redefinition using #define (conditionally > > for static linking in OpenJDK, as Coleen suggested earlier) for now, until > > the tooling can support symbol localizing better. Then localizing symbols > > using tools like `objcopy` can be the longer term and cleaner solution, > > instead of using namespace. What's your thoughts on that? > > I suppose so, but why? > > Why should any of this have to work on old systems? If their binutils is > broken, static linking of openjdk won't work there. We ran into issues with older gcc on linux-aarch for partial linking, but the problem may not be older gcc only(?). At the current stage, limiting static/hermetic Java runtime support to only the platforms that support partial linking and `objcopy` seems to be overly restrictive (it does simplify the requirements significantly however :-)): - The duplicate symbol problems are mostly found in JDK natives and have been resolved already. We've found very few symbol issues with hotspot code so far. As there are portable alternative solutions that can resolve the symbol issues in hotspot, choosing a less portable solution seems not too attractive currently. - As we haven't found many duplicate symbol issues with hotspot code, resolving them case by case may still be a good choice. We don't have to tie into any permanent solution during the early stage. - Based on what we learned from the static/hermetic Java prototyping and investigations, majority of the work is non-os and non-cpu specific. If we can carefully handle the platform specific part with portable solution(s), we can support static/hermetic Java for different supported platforms as a more general solution. Those are my reasonings. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916047210
