Hi Joe,
On 6/05/2023 12:21 am, Joe Braley wrote:
Hi David,
Yes, this is still an issue our team is experiencing.
Okay I'm asking around but I'm not sure anyone actively uses jaotc any more.
David
Regards,
Joe Braley
-----Original Message-----
From: David Holmes <david.hol...@oracle.com>
Sent: Friday, May 5, 2023 12:24 AM
To: Joe Braley <joebra...@microsoft.com>; build-dev@openjdk.org
Subject: [EXTERNAL] Re: Compiler/aot testing on MacOS
[You don't often get email from david.hol...@oracle.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Joe,
It looks like you were not subscribed to the mailing list and this email only
just got cleared and has turned up. is this still an issue?
Cheers,
David
On 24/03/2023 12:20 am, Joe Braley wrote:
Hello,
Our team publishes Microsoft's build of OpenJDK, and we have observed
some test failures after upgrading our macOS agents from 10.15 to
MacOS 11. We have also seen these failures on macOS 12.x. The tests
that are encountering issues are in compiler/aot category.We are only
observing these issues in our JDK11u builds. The exact command line I
used to reproduce the error locally is:
/Users/JEG/jdk-11.0.18+10/Contents/Home/bin/java -Xmx512m -jar
/Users/JEG/jtreg/lib/jtreg.jar -agentvm -ignore:quiet -automatic -xml
-vmoption:-Xmx512m -timeoutFactor:4 -concurrency:1
-testjdk:/Users/JEG/jdk-11.0.18+10/Contents/Home -nativepath:/
Users/JEG/jdk-11.0.18+10-test-image/hotspot/jtreg/native
-verbose:fail,error,summary
-exclude:test/hotspot/jtreg/ProblemList.txt
test/hotspot/jtreg/compiler/aot/TestHeapBase.java
Which resulted in the following exception:
Exception in thread "main" java.lang.InternalError: ld: dynamic main
executables must link with libSystem.dylib for architecture x86_64
at
jdk.aot@11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142)
<mailto:jdk.aot@11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142)>
at jdk.aot@11.0.18/jdk.tools.jaotc.Main.run(Main.java:262)
<mailto:jdk.aot@11.0.18/jdk.tools.jaotc.Main.run(Main.java:262)>
at jdk.aot@11.0.18/jdk.tools.jaotc.Main.run(Main.java:133)
<mailto:jdk.aot@11.0.18/jdk.tools.jaotc.Main.run(Main.java:133)>
at jdk.aot@11.0.18/jdk.tools.jaotc.Main.main(Main.java:89)
<mailto:jdk.aot@11.0.18/jdk.tools.jaotc.Main.main(Main.java:89)>
The version of macOS which I reproduced this error was:
openjdk-jdk11u % sw_vers
ProductName: macOS
ProductVersion: 11.4
BuildVersion: 20F71
Initial triage on our end suggests that the linker for these tests is
invoked in Linker.java, where we may require additional arguments
passed into the "ld" command. Specifically, including the library
path. The change that may have introduced this behavior is documented here:
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes
<https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes>.
The important bit, I think, is:
* /New in macOS Big Sur 11.0.1, the system ships with a built-in
dynamic linker cache of all system-provided libraries. As part of
this change, copies of dynamic libraries are no longer present on
the filesystem. Code that attempts to check for dynamic library
presence by looking for a file at a path or enumerating a directory
will fail. Instead, check for library presence by attempting to
dlopen() the path, which will correctly check for the library in the
cache. (62986286)/
Has anyone encountered this issue before or would be willing to
provide insight to what the root cause may be?
Thanks!
*Joe Braley
*Software Engineer
joebra...@microsoft.com <mailto:joebra...@microsoft.com>
Microsoft Logo
