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