search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k stars 721 forks source link

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

Closed Mesbah-Alam closed 4 years ago

Mesbah-Alam commented 5 years ago

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 commented 5 years ago

FYI .. @pshipton @AdamBrousseau

AdamBrousseau commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago 
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 commented 5 years ago

@AdamBrousseau - white space has been added : https://github.com/eclipse/openj9-systemtest/pull/58

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

AdamBrousseau commented 5 years ago

Can this be closed then?

Mesbah-Alam commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

DanHeidinga commented 5 years ago

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 commented 5 years ago

Not a blocker for the 0.12 release.

DanHeidinga commented 5 years ago

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

AdamBrousseau commented 5 years ago

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

Mesbah-Alam commented 5 years ago

Is there any update on this?

jdekonin commented 5 years ago

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.