On Mon, 22 May 2023 21:27:58 GMT, Jiangli Zhou <jian...@openjdk.org> wrote:
>> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for >> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for >> handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for >> static-libs-image/static-libs-bundles targets; This change does not affect >> the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a >> different JDK library and needed when creating the .so shared library only) >> from JDK .a libraries; That's to avoid linker failures caused by duplicate >> symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o >> zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since >> it's provided in libawt.a >> >> - Handle long arguments case for static build in >> make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in >> https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for >> LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx-<cpu> platforms: >> >> - For gcc/clang, when building a static library first partially link (using >> the `-r` linking option) all object files into one object. The output object >> file from the partial linking is then passed to `ar` to create the static >> library. >> >> The original change for JDK-8307194 used @argument_file for all platforms >> when dealing with long arguments to `ar`, which caused failures on >> macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), >> `ar` does not support @argument_file. The updated change avoids using >> @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The >> flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request incrementally with one additional > commit since the last revision: > > - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) > is gcc or clang, as suggested by @erikj79. 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 make/common/NativeCompilation.gmk line 1210: > 1208: ifneq ($(findstring $(TOOLCHAIN_TYPE), gcc clang), ) > 1209: $$(call ExecuteWithLog, > $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1210: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) > $$($1_SYSROOT_LDFLAGS) \ Mac builds failed in our distributed system. I believe this will fix it: Suggestion: $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \ $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ It also looks like the indentation in this block is off, 3 spaces instead of 4. ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1442698087 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1204726154
