On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson <er...@openjdk.org> wrote:
> > My build job is still running, but it has failed in two distinct ways > > already. See below for mac fix. Our cross build of arm32 fails with this > > message: > > ``` > > [2023-05-24T19:25:15,310Z] > > /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: > > fatal error: cannot mix -r with dynamic object > > /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > ``` > > If this is a problem with your partial link solution, then perhaps just > employing the relative path trick for the `ar` command line on mac could be > enough to handle long paths and lots of object files? That appears to be how > we handle it with clang for linking already due to @-file problems. The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561969001
