On Wed, 24 May 2023 21:47:49 GMT, Jiangli Zhou <jian...@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? Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1562128417
