BLD: Enable build on AIX #8173
BLD: Enable build on AIX #8173
Conversation
| if sys.platform[:3] == "aix": | ||
| defs = [('_LARGE_FILES', None)] | ||
| else: | ||
| defs = [('_FILE_OFFSET_BITS', '64'), | ||
| ('_LARGEFILE_SOURCE', '1'), |
There was a problem hiding this comment.
Indentation. the list contents should align vertically.
|
Minor style nit. Is this likely to be AIX/Python version dependent? Could you also squash the commits and follow the commit message guidelines in |
charris
changed the title
|
I would repeat the test, but my NAS died - so I am 2000km away, and waiting for someone to come home and reboot the NAS - hopefully the degraded array will be awake long enough to rebuild the array. As to needed in random - was a surprise to me as well. I thought I was finished when I had done "core". But a test build failed in the new area and I looked in all the setup.py files for "LARGE" settings. Only random/setup.py had the same defines as core/setup.py just different way of specifying them. As to comments, deleting them or modifying them - I only started using git yesterday. I was happy that I even got it pushed to my fork. Thank you for the wise and friendly words! FYI: the setting, better define, is compiler independent - same issue occurs with both gcc and xlc. |
|
@aixtools The process for squashing and rewriting commit messages goes as follows for your three commits. First |
|
thx @charris - will work on that. Server (NAS disk died) yesterday, so in process of rebuilding. Last (key) message: Further, my commit message will be something in the line of: As early as 1997 AIX started supporting so-called "large files", i.e., length > signed 32-bit. The convention became define flag _LARGE_FILES - before including any system include files (so that no relevant function calls would be redefined later in the build process). The "cleanup" is yet to come. If the commit message is missing something you feel is missing, please advise. |
… declarations
The problem this fix resolves is to ensure that 32-bit and 64-bit functions
(e.g., fclear() and fclear64()) to access/manipulate "large files" are
defined properly - much as GNU and other platforms use one or more of
the defines _FILE_OFFSET_BITS, _LARGEFILE_SOURCE, and _LARGEFILE64_SOURCE.
Without this fix the numpy code only defines flags that are not recognized
in the AIX environment and have no effect in anyway.
The fix applies the AIX convention and does not "export" any of the flags
currently exported. For all other platforms the current flags:
_FILE_OFFSET_BITS, _LARGEFILE_SOURCE, and _LARGEFILE64_SOURCE are "exported".
This fix should not have any impact or side-effect based on the version
of python used.
History:
Starting around 1997 AIX started supporting so-called "large files",
i.e., length > signed 32-bit. In the period 1997-1998 the flag _LARGE_FILES
was established to simplify porting 32-bit applications to 64-bit.
The convention is to define _LARGE_FILES before including any
"system include files" either as an argument to ${CC} (e.g., in ${CFLAGS}
or as the first #define in every source file. This is to ensure that
that no relevant function calls would be redefined later in the build process.
|
I have done the "squash" and message update as requested. I did not create a new pull request. Is that (also) needed? re: your final question: "Is there a way to be sure that it isn't needed elsewhere?" - basically, anywhere you need (one of) _FILE_OFFSET_BITS, _LARGEFILE_SOURCE, and _LARGEFILE64_SOURCE - _LARGE_FILES should be used for AIX. These current defines do not exist in AIX system files. |
|
I fixed up the indentation. That will modify your branch on origin. Yes, Github gives committers access to the PR branch ;) Just thought I'd give it a try. |
|
Thanks @aixtools . |
|
@aixtools does this mean we can close the numpy and scipy issues you opened, or is there more to do? |
|
The second issue with scipy (also _LARGE_FILES related imho) will first need similar treatment. But the first part, i.e., the first message scipy #6685 is not handled yet (as I replied by email, numpy has a similiar name issue with added _ (underscrore) to lapack names. |
|
excuse me for asking: I am not smart enough to find, or worse understand the documentation re: how I get/keep my forked copy in sync. |
|
Usually you have entries in you local repository for "origin", which is your githup forked numpy repo, and "upstream", which is the numpy github repo. I keep my local repo up to date by pulling from upstream, i.e., if I have master checked out The |
|
The development docs could be clearer on how to keep master in sync, I added something in gh-8205. |
|
On 23-Oct-16 16:23, Charles Harris wrote:
The info below is enlightening. I cannot place it all immediately, but But my lack of understanding git - ;) might not be standard for everyone! Thanks for the homework (tomorrow).
|
|
On 22-Oct-16 23:02, Ralf Gommers wrote:
From memory there is a "common" issue I am running into when I use the So: a) I shall review the scipy issues I have opened and close it if I b) for lapack and numpy I shall open a new issue when I have time to Michael |
|
Thanks Michael. Will close gh-8118 then. |
modifying two setup.py files to define _LARGE_FILES if sys.platform[:3] == aix: resolves this issue.