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

Reply via email to