Hello Vladimir,
I just checked and the toolchain we use on Linux at Oracle (produced by
the make/devkit scripts) isn't setting --as-needed either (while the
local toolchain on my Ubuntu machine does). From my understanding of
that flag, it's not something we really want to be set. It would be
better to identify libraries that we don't actually need and stop
linking against them. If setting --no-as-needed helps fixing this issue,
then that seems like a reasonable workaround to me.
/Erik
On 8/16/23 21:44, Vladimir Petko wrote:
Hi,
It looks like Adoptium is building with CentOS 6.10[1] which does not
append --as-needed linker flag by default. This results in the
.gnu_version section created and the bug worked around with Temurin
builds.
In Debian/Ubuntu the toolchain automatically uses -as-needed by
default so we've forced the --no-as-needed flag recently[2] to resolve
this issue[3].
I wonder if it is an acceptable solution to add '--no-as-needed' to
BASIC_LDFLAGS in make/autoconf/flags-ldflags.m4 to have consistent
linking?
Best Regards,
Vladimir.
[1]
https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-linux-x64-temurin/lastBuild/consoleFull
[2]
https://salsa.debian.org/openjdk-team/openjdk/-/commit/b9b80f7da869be0ee42fbb2dd18486b7b0a1826c
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031521
On Thu, Jun 29, 2023 at 7:06 PM David Holmes <[email protected]> wrote:
Hi Vladimir,
This is not the first time this has come up:
https://mail.openjdk.org/pipermail/build-dev/2020-February/026730.html
but no real resolution.
David
On 27/06/2023 6:31 pm, Vladimir Petko wrote:
Dear Maintainers,
There is a bug[1] submitted in Debian that a number of games crash
with the assertion
Inconsistency detected by ld.so: dl-lookup.c: 107: check_match:
Assertion `version->filename == NULL || ! _dl_name_match_p
(version->filename, map)' failed!
The investigation points to JAWT_GetAWT function from libjawt.so.
In Java 8 the build system supplied a mapfile which set the symbol
version for JAWT_GetAWT. It is no longer the case for Java 11+ due
to JDK-8200178.
If the native library was linked against Java 8 (e.g. lwjgl 2.x) then
it would be linking against the versioned symbol.
The assertion in the loader only fires when the version section
(.gnu.version) is absent, otherwise the loader provides the default
version of the function. This allows Temurin builds to work with those games.
I wonder if some of the map files could be reverted for the
compatibility reasons with Java 8, or it is not a recommended
approach?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031521
