AIX 7.1 with GCC/GFortran - Issue needing resolution

[Teej42]

I did review Issue 463.

I set up everything using the packages provided here. This includes the makefile, GCC and GFortran for AIX 7.1, Python 2.7, and so on. My objective is to get OpenBLAS set up to get SciPy module working (due to Lapack/BLAS dependency) for Python 2.7.

I updated Makefile.system to comment out the -m32/-m64 as noted in Issue 463:

#ifndef BINARY_DEFINED
#ifdef BINARY64
#CCOMMON_OPT += -m64
#else
#CCOMMON_OPT += -m32
#endif
#endif

I ran this:

/opt/freeware/bin/make FC=gfortran TARGET=POWER8 >result.txt 2>error.txt

But in the error.txt, I get this:

Assembler:
/home/fp/OpenBLAS-0.2.20/tmp/cc7zjwrP.s: line 71: Error In Syntax
/home/fp/OpenBLAS-0.2.20/tmp/cc7zjwrP.s: line 72: invalid opcode or pseudo-op
/home/fp/OpenBLAS-0.2.20/tmp/cc7zjwrP.s: line 73: Error In Syntax
/home/fp/OpenBLAS-0.2.20/tmp/cc7zjwrP.s: line 100: Error In Syntax
/home/fp/OpenBLAS-0.2.20/tmp/cc7zjwrP.s: line 101: Error In Syntax
make[1]: *** [Makefile.L1:622: sasum_k.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Assembler:
/home/fp/OpenBLAS-0.2.20/tmp/ccVmE6OQ.s: line 63: Error In Syntax
/home/fp/OpenBLAS-0.2.20/tmp/ccVmE6OQ.s: line 64: invalid opcode or pseudo-op
/home/fp/OpenBLAS-0.2.20/tmp/ccVmE6OQ.s: line 65: Error In Syntax
/home/fp/OpenBLAS-0.2.20/tmp/ccVmE6OQ.s: line 85: Error In Syntax
/home/fp/OpenBLAS-0.2.20/tmp/ccVmE6OQ.s: line 86: Error In Syntax
make[1]: *** [Makefile.L1:667: scopy_k.o] Error 1
make: *** [Makefile:139: libs] Error 1

How exactly should I address this?

As an aside, how exactly should $(OSNAME) get defined, so this would be correctly set:

ifeq ($(OSNAME), AIX)
BINARY_DEFINED = 1
endif

[Teej42]

Output/error/config.h/Makefile.conf as was requested in the other issue. Please let me know if you need anything else.

result.txt
error.txt
config.h.txt
Makefile.conf.txt

[martin-frbg]

Is there a specific reason why you would want to build 0.2.20 (which predates the fixes mentioned at the end of #463 ? Latest stable release is 0.3.3, you could also try a snapshot of the current "develop" branch.(And OSNAME gets defined by the c_check utility based on the output of gcc -E)

[Teej42]

I got 0.2.20 from this page - http://www.openblas.net - which I now realize is clearly no longer being maintained. I will pull the latest version and try. Will update this accordingly.

Also, did try gcc -E just now, and it demands an input file. I will investigate the proper way to call gcc -E.

[martin-frbg]

Sorry, gcc -E ctest.c is what c_check uses (and ctest.c is basically a bunch of ifdefs that prints out OS_AIX if the compiler defines _AIX). The situation with the openblas.net page is unfortunate indeed, I only have commit/release rights to the code repository.

[Teej42]

Thank you. I confirmed that it recognize OS_AIX, and interestingly enough ARCH_POWER, not POWER8, even though prtconf indicates that Processor Type is PowerPC_POWER8. So I tried:

/opt/freeware/bin/make FC=gfortran TARGET=POWER >result.txt 2>error.txt

It went in a different direction, and produced the following message:

zblat3.f:1447:0: Warning: 'REALPART_EXPR ' may be used uninitialized in this function [-Wmaybe-uninitialized]
ld: 0711-317 ERROR: Undefined symbol: .get_num_procs
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
ld: 0711-317 ERROR: Undefined symbol: .get_num_procs
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
make[1]: *** [Makefile:137: dblat1] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:134: sblat1] Error 1
make: *** [Makefile:124: tests] Error 2

Results: 32bitcompile.zip

I also tried:

/opt/freeware/bin/make BINARY=64 FC=gfortran TARGET=POWER >result.txt 2>error.txt

Got thrown with a whole bunch of this:

ar: 0707-126 dlasd3.o is not valid with the current object file mode.
Use the -X option to specify the desired object mode.

Results: 64bitcompile.zip

I will grab the latest dev package after lunch, and will also investigate both results closely then to hopefully find a workaround.

Hopefully this is something that have already been seen somewhere else.

[brada4]

zblat ... undefined symbol
You need to run "make clean" between compilation runs.

0707-126 ...
From the error format it seems that xlc or aix ar is used where gcc expects GNU binutils ar
While the object format is compatible GNU ar manpage states:

       -X32_64
           ar ignores an initial option spelt -X32_64, for compatibility with AIX.  The behaviour produced by this option is the default for GNU ar.  ar does not support any of the other -X options; in particular, it does not support -X32 which is the default for AIX ar.

EDIT: it seems that gcc does not add -X32_64 option so AIX ar does not work.

There are no AIX-specific fixes between 0.3.3 and develop, you can stay with release until any fix is posted in relation with this issue.

[Teej42]

Re: make clean:

364 vi error.txt
365 /opt/freeware/bin/make clean
366 /opt/freeware/bin/make FC=gfortran TARGET=POWER >result.txt 2>error.txt
367 vi error.txt
368 ls
369 ls -altr
370 /opt/freeware/bin/make clean
371 /opt/freeware/bin/make BINARY=64 FC=gfortran TARGET=POWER >result.txt 2>error.txt
372 vi error.txt

---

I will look into whether we're referencing the right ar or even if we have a copy installed, and update this accordingly.

[brada4]

I see one in AIX RPM collection. Probably you need to prepend that bin/ path so that GNU tools override AIX ones.

[martin-frbg]

At least in theory, identification of ARCH_POWER should lead to a call to cpuid_power that returns TARGET=POWER8, so specifying TARGET=POWER on the command line should not be necessary (and might even be detrimental). Unfortunately #463 was just lots of back and forth with the original poster leaving as soon as we got it to build "somehow", but the -X 64" argument to IBM ar should already be generated by Makefile.power.

[brada4]

There is $CC invoked at the end twice, to link final shared library and to run linktest.

[martin-frbg]

From your logs it looks as if ar -X 64 does get called already, perhaps this actually needs to be "-X64" without the intervening blank (line 62 of Makefile.power).
(And building with TARGET=POWER apparently led to a build for POWER5, which may not be what you want)

[Teej42]

I can confirm that with the 0.3.3 release, the -x 64 issue is all properly resolved, so I did not need to do any modification to the Makefile.system.

---

I installed binutils, and ran the following commands:

$ export PATH=/opt/freeware/bin:$PATH

This to trigger the use of GNU ar.

$ make clean
$ make

This threw an error for ar:

ar -X 32 -ru ../libopenblas_power5p-r0.3.3.a saxpy.o sswap.o scopy.o sscal.o [blahblahblah]
ar: invalid option -- X
Usage: ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin ] [member-name] [count] archive-file file...
ar -M [<mri-script]
[information]
emulation options:
[-g] - 32 bit small archive
[-X32] - ignores 64 bit objects
[-X64] - ignores 32 bit objects
[-X32_64] - accepts 32 and 64 bit objects

So whitespace between -X and the digit are verboten for this particular AR install. Version:

$ ar -V
GNU ar (GNU Binutils) 2.25.1
Copyright (C) 2014 Free Software Foundation, Inc.

I am digging around to find out where the -X 32 is triggered, and see if I can fix the whitespace myself.

---

As I just wrote this, Martin responded with the fix which I addressed, and tried make again. Unfortunately, I still have to use FC=gfortran, as xlF is continued to be referenced to.

So in summary, things that AIX needs that I have identified so far:

1. GCC and its dependencies.
2. GFortran and its dependencies (xlF chokes unfortunately, even though we already have it installed).
3. GNU binlibs.
4. GNU make (AIX make chokes on the Makefile)
5. makefile.power to have the fix for -X 64 and -X 32 changed to -X64 and -X32.

And it failed here:

ranlib ../../libopenblas_power5p-r0.3.3.a
ar: 0707-108 File ../../libopenblas_power5p-r0.3.3.a is not an archive file.
ranlib: 0654-601 Execution of ar failed
Usage: ranlib [-t] [-X {32|64|32_64}] [--] file ...
make[2]: *** [Makefile:557: ../../libopenblas_power5p-r0.3.3.a] Error 1
make[2]: Leaving directory '/medstat/fp/download/OpenBLAS/lapack-netlib/SRC'
make[1]: *** [Makefile:21: lapacklib] Error 2
make[1]: Leaving directory '/medstat/fp/download/OpenBLAS/lapack-netlib'
make: *** [Makefile:225: netlib] Error 2

Logs: 2-32bitcompile.zip

Running BINARY=64 option after cleaning.

[martin-frbg]

What does file libopenblas_power5p-r0.3.3.a think what it is, if it is "not an archive file" ? Or does the numeric part of the error message suggest that ranlib managed to still invoke the AIX ar (which may not like the output that its gnu cousin prepared) ? Not sure if we saw anything like that in #463

[Teej42]

I did a which ranlib which shows it's still referring to /usr/bin/ranlib, so you're on the button on this. I did try changing the symbolic link under /usr/bin/ar to the right version, but ranlib continues to error out with the wrong settings for ar:

$ ranlib libopenblas_power5p-r0.3.3.a
ar: invalid option -- X

Then I looked into /opt/freeware/bin/ and discovered there's several ranlib files:

$ ls -1 |grep ranlib
gcc-ranlib
granlib
powerpc-ibm-aix7.1.0.0-gcc-ranlib

granlib was set as read only, so I changed the permission to 755, and it rans:

$ granlib libopenblas_power5p-r0.3.3.a
$ echo $?
0
$

So we need to update the makefiles to point to granlib, NOT ranlib, on AIX if using GNU programs (gcc/gfortran/gnu make, et cetera). I am currently investigating how to do this.

[martin-frbg]

It could be that you just need to set RANLIB=/opt/freeware/bin/granlib (however things will get complicated if granlib does not have execute permissions by default).
On the other hand, the issue may just come from using GNU ar for generating the archive, I am not sure if there really is a reason to avoid the AIX ar (beyond brada4's initial interpretation of the error message from the misspelled option)