BLD: define NO_APPEND_FORTRAN when libraries are built using xlf and/or xlc on AIX #15835
Conversation
|
Actually, this is "green", but GitHub status may not be posted on commits occasionally from build |
|
Did you add the original AIX support? I would like to ping someone who is more involved with AIX. The comment reads a bit as if this might actually break certain compilers (gfortran possibly behaving differently)? Is that a real issue or more a theoretical thing, or should this rather be detected, or an option? |
| # Note: this setting is actually dependent on the fortran compiler behavior | ||
| # used to build liblapack.a (xlf does not append!, maybe gfortran does) | ||
| # Better way to establish liblapack.a definition is needed. | ||
| defs = [('NO_APPEND_FORTRAN', None)] if sys.platform[:3] == "aix" else [] |
There was a problem hiding this comment.
If it's compiler-dependent it should go into IBMFCompiler in numpy/distutils/fcompiler/ibm.py instead I think.
There was a problem hiding this comment.
Not the correct approach - this is a flag for the C compiler - to interface with fortran (libraries). IMHO - it will be a real nightmare if the libraries mix behaviors.
In any case, the AIX provided libraries do not have an underscore (_) appended, but user libraries might.
I would also like to suggest a README.AIX, if not already available, and/or I a link to a project I am starting for CPython -- https://github.com/aixtools/pythonAIXDOC -- there is no reason to limit it to CPython - as I am trying to be the focal point for AIX and OSS porting.
Not pressing "resolved", just yet.
What is the original AIX support? atm I am the most involved AIX contributor. So, if you can find someone more involved - please let me know who this person is. I would love to collaborate more! The issue is not gfortran - directly at least, but how libraries are built. The link I added earlier in the discussion - from 2003 - stated that both AIX and HPUX did not use the appended underscore (_). Whether that is because gfortran always does (and the system libraries are built using f77/xlf) or gfortran - on AIX - also excludes the _ I cannot say. Rather than point at a compiler (imho, the wrong approach). Instead, I was thinking of adding a test to try and link to a routine with the underscore. If successful, nothing extra needs to be done as this is the default. However, if that fails, try the same test, but without the underscore - if that succeeds, then add the define. If this also fails - probably just "stop" because something else is wrong. |
You are, and it's much appreciated! No worries about "original", that's all lost in the mists of time. I will review AIX build fixes to the best of my ability.
Let's ping @ayappanec, he's been helpful with gfortran on AIX before IIRC.
Yes, this sound great - we do that in multiple places with |
|
Sorry, I was just fishing for someone more qualified than me to review this :), but I think your plan and Ralfs review is more than enough here anyway :). |
Sounds good. I also have gfortran (self built :p) - I'll try it eventually.
Ah, a string to search for - for examples!! |
No need for apology. I do wish you knew someone better than myself. (My ego is hard to surpass - rofl) |
|
We are maintaining openblas and netlib blas in AIX Toolbox. We build them using gcc (gfortran) and use GNU libtool script to create the symbols export file which is then used to create the shared libraries. The symbols " zungqr_ , zgeqrf_ ., etc are present in those libraries. |
|
Again, a check to see which is available. Again, I do not know if it is a behavior of gfortran to always add a underscore, but when linking against the libblas.a provided by As to AIX toolbox - if gfortran is always adding it, and gcc is always expecting it - that would explain why gcc and gfortran cannot use the version of libblas.a that falls under a support agreement. IMHO - the key, while compiling the .c files that integrate with fortran libraries is to have a check to establish what the libraries require for linkage. |
|
Again, just to be clear - it is not, imho, a correct approach to set or remove the underscore based on the compiler. The preferred solution is to use a test and see what the libraries require. For example, if the libraries are coming from AIX Toolbox then the underscore is needed. But then, maybe everything is coming from AIX Toolbox and a user is building nothing. As AIX is not, by default, a supported GNU run-time environment (xlC.rte is not, afaik, GNU compatible, and the GNU needs also depend on the specific GCC compiler used). This makes AIX more difficult to generalize - and ultimately, makes the importance of a README.AIX only more important to support administrators and/or developers who need to "build their own". |
|
Maybe we should split this PR into two parts. The |
|
@aixtools yes agreed, I think we're happy going with the
We'd rather keep any needed documentation in the html docs and link to it. The most extensive build details per platform are at http://scipy.github.io/devdocs/building/index.html#building, AIX can be added there. And it misses a link from https://numpy.org/devdocs/user/building.html#building-from-source I see now. |
I'll leave this one with the "underline-on-names" part - to preserve the discussion, and make a new PR for the _LARGE_FILES bit. |
aixtools
changed the title
|
I see there is now a conflict. Been a long while since I have looked at this. My goal - probably January - is to have two build systems - one XLC/XLF based, and another gcc/gfortran based - and re-validate this. |
|
Building with Meson on AIX should work - with |
Closes #15801
a) LARGE_FILES is needed by AIX for proper compilation (done by #15938 )
b) lapack, when compiled using xlf, does not need the underscore () added to the function name when calling fortran from C.