RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7]
Erik Joelsson
erikj at openjdk.org
Fri Jun 9 20:05:43 UTC 2023
On Thu, 8 Jun 2023 20:34:15 GMT, Jiangli Zhou <jiangli at 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 with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>
> - Merge branch 'master' into JDK-8307858
> - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
> - Merge branch 'master' into JDK-8307858
> - Address comments/suggestions from @erikj79:
> - Only do partial linking step for building static libraries with clang on linux.
> - On macosx, workaround the long argument issue for 'AR' with relative path.
>
> Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
> - Update make/common/NativeCompilation.gmk
>
> Thanks you!
>
> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
> - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
> - Update make/common/NativeCompilation.gmk
>
> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
> - Merge branch 'master' into JDK-8307858
> - Merge branch 'master' into JDK-8307858
> - Clean up.
> - ... and 9 more: https://git.openjdk.org/jdk/compare/c4e65425...c664c601
All our builds succeeded, so this is looking pretty good now. Just a minor suggestion left.
make/common/NativeCompilation.gmk line 1186:
> 1184: # Include partial linking when building the static library with clang on linux.
> 1185: ifeq ($(call isTargetOs, linux), true)
> 1186: ifneq ($(findstring $(TOOLCHAIN_TYPE), clang), )
This combination of conditions is repeated 3 times. Maybe we could assign the result to a variable (e.g. `$1_ENABLE_PARTIAL_LINKING`) and check for that instead?
-------------
PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1472988455
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1224714975
More information about the core-libs-dev
mailing list