On Mon, 27 Jan 2025 10:51:20 GMT, Joachim Kern <jk...@openjdk.org> wrote:
> The clang compiler which we use since jdk21 pollutes the burned-in library > search paths of the generated executables. > e.g. a dump -X64 -H ... /jdk-23.0.1+11-jre/lib/libnio.so > > amongst others produces the following lines > > ***Import File Strings*** > INDEX PATH BASE MEMBER > 0 > /opt/IBM/openxlC/17.1.1/../../../../usr/lpp/xlC/lib:/opt/IBM/openxlC/17.1.1/lib:/opt/IBM/openxlC/17.1.1/bin/../../../../../usr/lpp/xlC/lib:/usr/opt/zlibNX/lib:/opt/freeware/lib/pthread:/opt/freeware/lib:/usr/lib > > The long string is the burned in library search path which will be used after > searching with LIBPATH envvar. > You see there are some compiler paths which customers will not have; also > /opt/freeware is unwanted. > A proper executable should only have the burned in default search path > /usr/lib:lib > > To ensure this we want to call the linker with the flag > -fuse-ld=our-wrapper-script-cleaning-LIBPATH- > and-calling-original-ld-afterwards > This script we want to deliver in make/scripts/aix/ld.sh > just containing > #!/bin/bash > unset LIBPATH > exec /usr/bin/ld "$@" > return $? Unfortunately, there is no other way. The LIBPATH envvar during our build is already unset. The compiler itself, when called as the Linker is setting some paths into LIBPATH before he calls the real Linker by himself. This is the only way to get rid of the unwanted burned in paths. This was an advice from IBM to do so as a standard trick. I now checked in the script without x-Bit. Then during configure call it is copied to the build directory, where the x-Bit is set. -fuse-ld= Parameter points now to this copied version. If you are reluctant with this solution, we additionally can make it dependent from a new configure flag which we would set and nobody else. By the way, if we try to address this as a possible bug and this is very unlikely accepted by IBM, it will take at least half a year to get a change. And because this would change the behavior of the compiler I'm pretty sure this will only be included in a new Compiler not yet shipped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23313#issuecomment-2621176645
