RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4]

[Erik Joelsson]

On Mon, 22 May 2023 21:27:58 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 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