AIX 7.3 system

[aixtools]

Please put the name of the software product (and affected platforms if relevant) in the title of this issue

Details:

As AIX 7.1 is now retired (see #3030) I am creating this issue for tracking any issues that come during the running of the playbook for the first time on AIX 7.3 (@Haroon-Khel - I hope you can do this).

[aixtools]

Machine is installed with xlc13 and xlc16. The rest needs to be done using playbook (@sxa @Haroon-Khel )

Further, made a PR to rename the system as test-osuosl-aix73-ppc64-1

[sxa]

Thanks Michael!

[Haroon-Khel]

Thanks Michael, I will run the playbook on the machine

[Haroon-Khel]

An error when using Yum

root@adopt01:[/root]yum --version
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   No module named rpm

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.10 (default, Jun 22 2016, 05:57:59) [C]

If you cannot solve this problem yourself, please go to 
the yum faq at:
  http://yum.baseurl.org/wiki/Faq

Investigating a solution

[Haroon-Khel]

The thread in https://community.ibm.com/community/user/power/discussion/yum-broken-after-aix-73-upgrade suggests yum is no longer supported on AIX7.3, dnf is recommended

[Haroon-Khel]

https://community.ibm.com/community/user/power/blogs/sangamesh-mallayya1/2021/05/28/dnf-is-now-available-on-aix-toolbox?CommunityKey=10c1d831-47ee-4d92-a138-b03f7896f7c9&tab=recentcommunityblogsdashboard to install dnf

[Haroon-Khel]

dnf is installed, packages updated without error. Machine is online at https://ci.adoptium.net/computer/test-osuosl-aix73-ppc64-1/

[Haroon-Khel]

Will need to add the dnf install steps to the playbooks for aix7.3 machines

[Haroon-Khel]

aqa test pipeline job running on test-osuosl-aix73-ppc64-1 https://ci.adoptium.net/job/AQA_Test_Pipeline/155/console

[Haroon-Khel]

16:37:44  Caused by: hudson.plugins.git.GitException: Command "/opt/freeware/bin/git init /home/jenkins/workspace/Test_openjdk11_hs_sanity.functional_ppc64_aix/aqa-tests" returned status code 255:
16:37:44  stdout: 
16:37:44  stderr: Could not load program /opt/freeware/bin/git:
16:37:44    Dependent module /usr/jdk-17.0.7+7/../lib/libiconv.a(libiconv.so.2) could not be loaded.
16:37:44    Member libiconv.so.2 is not found in archive 

Added the LIBPATH=/opt/freeware/lib environment variable to the machine's jenkins config (to be consistent with other machines), still hitting the above error https://ci.adoptium.net/view/Test_grinder/job/Grinder/7418/console

From https://github.com/adoptium/infrastructure/issues/1006#issuecomment-565070473 I take it we want it to use /opt/freeware/lib/libiconv.a, which is present on the machine. I wouldve thought adding the LIBPATH=/opt/freeware/lib to the jenkins config fixes this

[aixtools]

These kind of errors are why I was never a fan of the AIX Toolbox. If you can file a PMR with IBM AIXToolbox team - I would do that. They need to fix this rather than potentially breaking things - continually - when you want to use their tools.

imho: they should have the libpath - when it deviates - in the executable (dump -H shows the built-in libpath).

[Haroon-Khel]

Looks like the LIBPATH value java uses can be overidden with the -Djava.library.path parameter . Using the java file below

public class Main {

  public static void main(String[] args) {
    System.out.println(System.getProperty("java.library.path"));
  }
}

jenkins@adopt01:[/home/jenkins]/usr/java17_64/bin/java Main
/usr/jdk-17.0.7+7/lib/server:/usr/jdk-17.0.7+7/lib:/usr/jdk-17.0.7+7/../lib:/lib:/usr/lib
jenkins@adopt01:[/home/jenkins]/usr/java17_64/bin/java -Djava.library.path="/opt/freeware/lib/" Main
/opt/freeware/lib/

[aixtools]

IMHO: they are asking for issues by putting their libraries first, rather than /usr/lib.

ALSO: if the default LIBPATH includes …/jdk-17*/… stuff, and using the -Djava.library.path argument erases all of those – I would expect different problems down the road – else – why bother with the /usr/jdk-17.0.7+7/lib/server:/usr/jdk-17.0.7+7/lib:/usr/jdk-17.0.7+7/../lib: bits in the first place – OR – maybe that is the bug – the wrong compiler, read linker, arguments putting unneeded Library paths.

My gut feeling is that using -Djava.library.path is treating a symptom, not resolving a problem.

@.***>

Michael Felt

Mobile +31 (0)6 5184 4181

Email @.***

From: Haroon Khel @.> Sent: Friday, August 11, 2023 5:07 PM To: adoptium/infrastructure @.> Cc: Michael Felt @.>; Author @.> Subject: Re: [adoptium/infrastructure] AIX 7.3 system (Issue #3142)

Looks like the LIBPATH value java uses can be overidden with the -Djava.library.path parameter . Using the simple java class below

public class Main {

public static void main(String[] args) { System.out.println(System.getProperty("java.library.path")); } }

@.:[/home/jenkins]/usr/java17_64/bin/java Main /usr/jdk-17.0.7+7/lib/server:/usr/jdk-17.0.7+7/lib:/usr/jdk-17.0.7+7/../lib:/lib:/usr/lib @.:[/home/jenkins]/usr/java17_64/bin/java -Djava.library.path="/opt/freeware/lib/" Main /opt/freeware/lib/

— Reply to this email directly, view it on GitHub https://github.com/adoptium/infrastructure/issues/3142#issuecomment-1674939042 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSZR5M2LX23SNI6RZZBTL3XUZC7ZANCNFSM6AAAAAA22AS67Q . You are receiving this because you authored the thread. https://github.com/notifications/beacon/ACSZR5LOVVOJFCFFU2CBTQ3XUZC7ZA5CNFSM6AAAAAA22AS67SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTD2WFKE.gif Message ID: @. @.> >

[sxa]

Do we know how to move this forward? It would be good to have an AIX 7.3 machine in the jenkins set for testing. We also have the system in https://github.com/adoptium/infrastructure/issues/3208 which is AIX7.3+xlc17 which we need to get set up, but we should aim to get both working as usable systems.

[sxa]

@Haroon-Khel Ref earlier conversation the above comments suggest the machine has not yet made it to being usable because there are issues with git - is that correct?

[Haroon-Khel]

Yes I believe that is still an outstanding issue

[sxa]

Downgrading to git-2.31.1-1.ppc with dnf (Same version as some of the other AIX systems) seems to have resolved this (see https://ci.adoptium.net/job/Grinder/8197/console - it has definitely got further), but a subsequent playbook run may try to update it, so this may require a version lock in the dnf configuration. Have also queued up a build job at https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-aix-ppc64-temurin/340/console That failed as the LDR_CNTRL_MAXDATA variable wasn't set on the agent startup. Resolved and re-running at https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-aix-ppc64-temurin/341/

[sxa]

Looks like it still has issues - maybe 32/64-bit related?

[2023-12-07T19:21:48.213Z] Updating support/src.zip
[2023-12-07T19:21:48.997Z] Could not load program /opt/freeware/bin/zip:
[2023-12-07T19:21:48.997Z] Could not load module /opt/freeware/lib/libbz2.a(libbz2.so.1).
[2023-12-07T19:21:48.997Z]  Dependent module /opt/freeware/lib/pthread/ppc64/libgcc_s.a(shr.o) could not be loaded.
[2023-12-07T19:21:48.997Z]  The module has an invalid magic number.
[2023-12-07T19:21:48.997Z] Compiling 127 files for java.compiler

Almost certainly a 32-bit libbz2 and trying to load a 64-bit libgcc_s, although an ldd -s against libbz2.so.1 insude the archive seems to show it's trying to pick up the 32-bit one from /opt/freeware/lib/libgcc_s.a which means it's probably some messing around with the search path that's being done during the build.

[sxa]

I'm done for now - someone else can take over this investigation and comparison with a working system :-) There is a /usr/lib64/libbz2.a that should correctly work with a 64-bit libgcc_s.a but it's not the one that's being picked up.