Using "../java" in system.c when looking for a shared library doesn't work on zOS

[groeges]

A change went in recently: #3176 to fix an issue with MacOS but this fix has broken the zOS builds. See issue: https://github.ibm.com/runtimes/openjdk-contribution/issues/631 for details of issue. This needs to be resolved in order to get the zOS builds working again.

[tajila]

Ill take a look at this

[groeges]

@tajila Any progress on this?

[tajila]

I have a PR eclipse/omr#3148

[pshipton]

Does the original change to use ../ only work because it fails to find the library at that path and falls back to search the portlib directory?

[tajila]

@pshipton yes

[pshipton]

@DanHeidinga is that really what you intended when you made the change?

[pshipton]

I think I'm still missing something. If "../java" always fails on Mac, and the fallback makes it work, wouldn't just using "java" have been sufficient on the Mac, as it could also fail and then use the fallback?

[tajila]

I'm not sure what happens on mac, I never tried it there. But on xa64 ../java only works because of the fallback.

[pshipton]

Perhaps I misunderstood. Does the fallback still use the ../java path, but from the portlib directory?

[DanHeidinga]

Does the fallback still use the ../java path, but from the portlib directory?

Yes. it makes the path relative to the portlib directory as libjava.so is up one level from the compressed | default directories

[DanHeidinga]

This may be a better approach for the openj9 code - #3535

Thought @tajila's OMR fix is a good thing to do as well to make the behaviour of the j9sl_open_shared_library consistent across platforms.

[pshipton]

#3535 was reverted
#3542 fixes the problem.