[EXTERNAL] Re: Compiler/aot testing on MacOS

[David Holmes]

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.holmes at oracle.com>
> Sent: Friday, May 5, 2023 12:24 AM
> To: Joe Braley <joebraley at microsoft.com>; build-dev at openjdk.org
> Subject: [EXTERNAL] Re: Compiler/aot testing on MacOS
> 
> [You don't often get email from david.holmes at 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 at 11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142)
>> <mailto:jdk.aot at 11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142)>
>>
>>           at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:262)
>> <mailto:jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:262)>
>>
>>           at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:133)
>> <mailto:jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:133)>
>>
>>           at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.main(Main.java:89)
>> <mailto:jdk.aot at 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
>> joebraley at microsoft.com <mailto:joebraley at microsoft.com>
>>
>> Microsoft Logo
>>