On Thu, 25 May 2023 01:19:11 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. I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17). @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light. For the `aarch64-linux-gnu` build using `devkit`, I see following, which is ok. No unexpected options are included. /.../bin/aarch64-linux-gnu-g++ -r --sysroot=/.../aarch64-linux-gnu/sysroot -o /...linux-aarch64-server-release/hotspot/variant-server/libjvm/objs/static/libjvm_relocatable.o @/.../hotspot/variant-server/libjvm/objs/static/_BUILD_LIBJVM_objectfilenames.txt ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564908324
