[External] : jdk build using devkit on RHEL puts path to devkit into libsplashscreen

[Baesken, Matthias]

Hi Erik, thanks for the fast reply .
I created

https://bugs.openjdk.org/browse/JDK-8315499

Best regards, Matthias


From: erik.joelsson at oracle.com <erik.joelsson at oracle.com>
Sent: Thursday, 31 August 2023 15:30
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.org; sgehwolf <sgehwolf at redhat.com>
Cc: Zeller, Arno <arno.zeller at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230901/23899c80/attachment-0001.htm>