Hi Erik, thanks for the fast reply . I created https://bugs.openjdk.org/browse/JDK-8315499
Best regards, Matthias From: erik.joels...@oracle.com <erik.joels...@oracle.com> Sent: Thursday, 31 August 2023 15:30 To: Baesken, Matthias <matthias.baes...@sap.com>; build-dev@openjdk.org; sgehwolf <sgehw...@redhat.com> Cc: Zeller, Arno <arno.zel...@sap.com> Subject: Re: [External] : jdk build using devkit on RHEL puts path to devkit into libsplashscreen Hello Matthias, That's certainly not wanted behavior. I checked and it doesn't happen in our builds. I think your assessment is correct that the -R flag culprit is introduced in X_LIBS from the builtin autoconf macros. Digging through the history, it happened in [1], which is a long time ago. Only removing -R on cross compile probably isn't correct. We should at least remove it when using a devkit/sysroot. Maybe the only time we should let it stay is if any of the explicit --with-x/--with-x-libraries are used? /Erik [1] https://bugs.openjdk.org/browse/JDK-8005855 On 8/31/23 06:02, 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
