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

Reply via email to