Sounds familiar ...
https://bugs.openjdk.org/browse/JDK-8261656 ?
David
On 31/08/2023 11:02 pm, Baesken, Matthias wrote:
Hello, by chance we noticed that a jdk build on RHEL Linux (ppc64le
if that matters) that uses a devkit puts the devkits folder into
the libsplashscreen.so binary .
See those objdump and ldd output :
objdump -x ./lib/libsplashscreen.so | grep PATH
RUNPATH
/mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN
ldd ./lib/libsplashscreen.so
ldd: warning: you do not have execution permission for
`./lib/libsplashscreen.so'
……..
libX11.so.6 =>
/mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 (0x00007fffa3920000)
libXext.so.6 =>
/mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 (0x00007fffa38e0000)
………
libz.so.1 =>
/mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libz.so.1 (0x00007fffa36f0000)
libc.so.6 => /lib64/power9/libc.so.6 (0x00007fffa34e0000)
libjvm.so => not found
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fffa3490000)
/lib64/ld64.so.2 (0x00007fffa3be0000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007fffa3460000)
This looks not really desired to me , why should the devkit be
referenced there (we do not ship it usually) ?
Looks like it is coming in via the X_LIBS setting , see
make/autoconf/lib-x11.m4
# Now let autoconf do it's magic
AC_PATH_X
AC_PATH_XTRA
* # AC_PATH_XTRA creates X_LIBS and sometimes adds -R flags. When
cross compiling*
* # this doesn't make sense so we remove it.*
if test "x$COMPILE_TYPE" = xcross; then
X_LIBS=`$ECHO $X_LIBS | $SED 's/-R \{0,1\}[[^ ]]*//g'`
fi
And X_LIBS is used later on Linux in the build of LIBSPLASHSCREEN .
Should we filter it out not only in the cross build but also when
building with the devkit ? Or is there some benefit in having the
devkit referenced ?
What is still unclear, why we do not see it when building on SUSE
instead of RHEL (maybe the linker behaves differently for some reason?) .
Best regards, Matthias
