On Tue, 30 Jan 2024 04:20:21 GMT, Jiangli Zhou <jian...@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. I believe this to be a mistake. HotSpot, by design, exports only the symbols intended for use by other components. Many of the symbol names are highly generic, and will conflict with application code. Sure, you have enough to be able to do some prototyping, but for real-world deployment you must be able to control symbol exports. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916535268
