Port IRAF to several architectures #31
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
olebole
added
the
Not to merge
olebole
force-pushed
the
local/porting
branch
2 times, most recently
from
6b3369b
to
9defb5a
Compare
olebole
added
enhancement
and removed
Not to merge
olebole
changed the title
Remark to big endian systemsIt seems that 32-bit big endian support was lost somewhere during the 64-bit port. 64-bit big endian systems were never supported by IRAF. IBM zSystems (s390x)the following comment may help:
The failing test is followed by which means: creation of a double precision floating point worked, but single precision not. |
olebole
force-pushed
the
local/porting
branch
2 times, most recently
from
6b4e848
to
b5f31c7
Compare
|
Pinging @lupinix for a review -- this PR may me the base to include other architectures for Debian/Ubuntu as well as for Fedora. Does this fit your needs wrt. other archs? |
olebole
force-pushed
the
local/porting
branch
8 times, most recently
from
628fa7d
to
ac2e144
Compare
olebole
changed the title
Note that big endian systems (MIPS, S390x) don't work in the moment. There were probably some bugs introduced during the 64-bit support.
Rename them to zsvjmp.S to run them through the preprocessor, add machine specific #ifdefs Not working: - s390x (Big Endian) - MIPS big endian, PPC64 big endian (little endians work) - x32 (unknown reason)
Instead of hardcoding "linux"/"macosx" to "-m32", the "-m32" flag must be given now as "CARCH" environment variable when starting make. This allows cross compilation on non-intel platforms that don't provide -m32.
|
Tested with Fedora, I also get the expected failures for the big endian architectures. In general you've taken all architectures into account which are supported by Fedora. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is used as a proof that the current structure is portable. While the ports are not complete (no documentation, minimal testing), they show that we didn't loose flexibility while cleaning up.
List of ports:
freebsd- untested, but should workfreebsd64- passes all testshurd- passes all tests, created as Debian packagelinux- passes all tests, created as Debian packagelinux64- passes all tests, created as Debian packagelinux- little endian passes all tests, created as Debian package; big endian failslinux64- little endian passes all tests, created as Debian package; big endian untested (but will fail)linux64- little endian passes all tests, created as Debian package; big endian untested (but will fail)linux- passes all tests, will be created as Debian packagelinux64- failing tests, see belowTo avoid filling up the
unix/subdir with too many (rarely used)as.foo/subdirs, all Linux archs are combined in twozsvjmp.Sfile (one for 32, one for 64 bit). See also this StackOverflow discussion about putting assembler for several architectures into one file. The freeBSD and Hurd subdirs are just links to the linux subdirs, so there is a chance that non-intel freeBSD ports will work as well.As a side effect, we get propagated
CFLAGSandLDFLAGS, which is nice to provide distribution specific changes during packaging.