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

[Jiangli Zhou]

On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson <erikj at 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
>
>> 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.

> > Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks
> 
> I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this:
> 
> ```
> .../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file
> ```
> 
> Any idea what that could be caused by or if it's possible to eliminate?

I observed the same warnings on my macosx-x86_64 local build. It's from the partial linking step. Not much information yielded when I searched for `ignoring unexpected dylib text stub file`. Search found https://opensource.apple.com/source/ld64/ld64-609/src/ld/InputFiles.cpp with the linker code throwing the warning (`dylibsNotAllowed` is true if `_options.outputKind` is `Options::kObjectFile`, which is related to what we are observing). 

I tried linking a `javastatic` executable using the static libraries created with partial linking on macosx-x86_64 last week. I was able to execute `javastatic` in my quick test but didn't go further for more verification, as the runtime didn't work with the static build yet. 

Haven't found any information on how to suppress the warning either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561913004