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

[erik.joelsson at oracle.com]

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/20230831/540dd18a/attachment.htm>