System test fails to compile on osx1011-x86-1 but compiles on osx1011-x86-2

[Mesbah-Alam]

System test fails to compile on osx1011-x86-1 but compiles on osx1011-x86-2 - the two machines should have the same behaviour but they do not.

Also, on osx1011-x86-1, we see one additional error: couldn't understand kern.osversion '15.6.0'

Full error message while compiling the native JlinkTest.c :

00:53:50      [exec] couldn't understand kern.osversion `15.6.0'
00:53:50      [exec] couldn't understand kern.osversion `15.6.0'
00:53:50      [exec] ld: unknown option: -o/Users/jenkins/workspace/Test-extended.system-JDK11-osx_x86-64_cmprssptrs/openjdk-tests/systemtest/openjdk-systemtest/openjdk.test.modularity/bin/tests/com.test.jlink/native/bin/osx_x86-64/libJniTest.so
00:53:50      [exec] collect2: ld returned 1 exit status
00:53:50      [exec] make[1]: *** [/Users/jenkins/workspace/Test-extended.system-JDK11-osx_x86-64_cmprssptrs/openjdk-tests/systemtest/openjdk-systemtest/openjdk.test.modularity/bin/tests/com.test.jlink/native/bin/osx_x86-64/libJniTest.so] Error 1```

 

[Mesbah-Alam]

FYI .. @pshipton @AdamBrousseau

[AdamBrousseau]

@Mesbah-Alam I think PR209 got us past the first compilation error. Rebuild on the same machine here. Still fails for the same reason but further along. Is there another instance in your code where you're missing a whitespace?

[Mesbah-Alam]

@AdamBrousseau - yes, same issue happened in another place. I'll fix that one. However, the issue still remains as to why the absence of whitespace after -o only causes compile failure on osx1011-x86-1 while it works on the other osx machines.

[AdamBrousseau]

osx1011vm1:~ jenkins$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-136
configured to support archs: armv6 armv7 armv7s i386 x86_64
LTO support using: LLVM version 3.2svn, from Apple Clang 4.2 (build 425.0.28)

osx1011vm2:~ jenkins$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-274.2
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.0.0, (clang-800.0.42.1)
TAPI support using: Apple TAPI version 1.30

cc @cwillhelm

[Mesbah-Alam]

@AdamBrousseau - white space has been added : adoptium/openj9-systemtest#58

System test now builds fine in osx1011-x86-1 : https://ci.eclipse.org/openj9/view/Test/job/Test-Grinder/127/consoleFull

[AdamBrousseau]

Can this be closed then?

[Mesbah-Alam]

Have we resolved the difference in configuration in the failing machine to the one where it doesn't fail? Do we need to have same configuration for all machines?

[cwillhelm]

It looks like these machines have a different version of LLVM based on @AdamBrousseau's comment above. Configuring LLVM wasn't part of the configuration steps for these machines, so it must just happen that one has a more recent patch than the other. If that isn't the issue, then I'm not sure what it could be.

[Mesbah-Alam]

Configuring LLVM wasn't part of the configuration

Since the tests have been updated and tested to run successfully on that particular failing machine, this should no longer be a build blocker. So, I don't have any objection closing the issue at this point -- if you are okay to go forward with the exception.

@AdamBrousseau @cwesMills

[pshipton]

@DanHeidinga fyi
I think we'd prefer to have the same configuration across machines.

[DanHeidinga]

I think we'd prefer to have the same configuration across machines.

Agreed. Let's keep this open until the machine configuration has been made consistent.

[pshipton]

Not a blocker for the 0.12 release.

[DanHeidinga]

@AdamBrousseau @cwesMills any update on updating the machines to be consistent with Adopt? In particular the LLVM version on OSX?

[AdamBrousseau]

Not from me. That would be a task for @cwillhelm but I'm not sure where it falls on his list.

[Mesbah-Alam]

Is there any update on this?

[jdekonin]

Instructions as per #3323 were to install xcode4 and xcode7, setting the default to xcode7. I had missed that for the JDK8 machine installs so hadn't passed that on to @cwillhelm for the initial machine installs. However, it seems that something extra happened on osx1011vm2 so I dug deeper.

osx1011vm1:~ jenkins$ clang --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
...
osx1011vm1:~ jenkins$ xcode-select -print-path
/Users/jenkins/Xcode4/Xcode.app/Contents/Developer
...
osx1011vm1$ sudo xcode-select -switch /Users/jenkins/Xcode7
...
osx1011vm1:~ jenkins$ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)

And on osx1011vm2 it appears that xcode-select --install was performed because v8 is installed with that method and made default. I left osx1011vm2 as it is for the time being, since the clang version isn't a blocker to system test as per @Mesbah-Alam comment above, but if there are no objections, I'll uninstall /Library/Developer/CommandLineTools aka clang 8 as it was not apart of the original setup instructions. @pshipton / @DanHeidinga +1 for agreement please?

osx1011vm2:~ jenkins$ clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Edit: there is no current playbook at Adopt for OSX. In fact, @cwillhelm currently has a pr open for an initial version. but I will update the adopt issue and pr if we have agreement to xcode7 being default as per #3323.