On Fri, 19 May 2023 20:18:53 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. I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 make/common/NativeCompilation.gmk line 1208: > 1206: $$(call ExecuteWithLog, > $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) > $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > 1208: $$($1_LD_OBJ_ARG)) This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: ld: library not found for -lSystem ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1435143793 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199405809
