#28 p7zip version 15.09 fails to build on s390

[Sinny Kumari]

Hi,

p7zip version 15.09 fails to build on s390, 32 bit architecture. I checked this on Fedora 21 and later releases. Following is the build error message :
-DUNIX_USE_WIN_FILE -DEXTRACT_ONLY -DNO_READ_FROM_CODER -D_SFX ../../../../CPP/myWindows/mySplitCommandLine.cpp
../../../../CPP/myWindows/mySplitCommandLine.cpp:99:8: error: #error ENDIANNESS
#error ENDIANNESS
Complete build log is avilable at http://s390.koji.fedoraproject.org/kojifiles/work/tasks/4855/1994855/build.log .

Reason of this build failure is that it doesn't recognize s390 architecture as big endian. I have proposed a patch (available in attachment) which allows to recognize both s390 and s390x as big endian. With this patch, p7zip builds fine on s390(x) as well.

Thanks

[Igor Pavlov]

Better patch to support also zarch:

    || defined(__s390__) \
    || defined(__s390x__) \
    || defined(__zarch__) \
    || (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__))
  #define MY_CPU_BE

[Sinny Kumari]

Not sure, if it is important to check for macros __s390x__ and __zarch__ for arches s390x and zarch. By looking into gcc source code https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/s390/s390-c.c;h=fa69ed31fe5f1ad0f73dbcd1c1acab3afef85638;hb=HEAD#l296 , it appears that __s390__ macro is defined for s390, s390x and zarch arches.

[Igor Pavlov]

• it appears that s390 macro is defined for s390, s390x and zarch arches.

Is it so for any version of gcc?
Some another programs also check all off them: __s390__ __s390x__ __zarch__.

[Sinny Kumari]

I was looking into commit log of gcc and noticed that__s390__was first introdcued in gcc during year 2002 with commit https://github.com/gcc-mirror/gcc/commit/61b914265a93af0ff15ab294fa6beb30405dd051#diff-cad03287b432a4033eb7a02d16072b9dR80 . From the commit, it seems check for macro __s390__ is suffecient to know archtecture is either s390 or its successor.

[Igor Pavlov]

Are there C / CPP compilers (some old GCC or some another compiler, for example, some compiler from IBM) that can use __s390x__ or __zarch__ without __s390__?

[Dan Horak]

That's a good question, the s390 being defined for both 32 and 64 bit s390 is IBM decision (they do provide the s390 support in the compilers, I'm not aware of any purely community developed compiler), so all compilers should follow the scheme. AFAIK there is no 32-bit compiler in LLVM for s390. Although using only s390 should be safe, it might be actually better to check for both s390 and s390x.

[Igor Pavlov]

Actually crypto++ checks all of them:
http://www.cryptopp.com/docs/ref/config_8h_source.html
So I supposed that I can do it in 7-Zip too.

[Dan Horak]

no objections :-)

[Robert Luberda]

Actually p7zip fails to build on a few more archs like alpha (see [1] below) or sparc64 ([2]) because of

../../../../CPP/myWindows/mySplitCommandLine.cpp:99:8: error: #error ENDIANNESS
       #error ENDIANNESS
        ^

I've fixed the issue by #including <endian.h> and checking BYTE_ORDER - please see the attached patch. (Alternative approach would be to check __BYTE_ORDER if defined, which is gcc extension)</endian.h>

Build logs:
[1] https://buildd.debian.org/status/fetch.php?pkg=p7zip&arch=alpha&ver=15.09%2Bdfsg-1&stamp=1455414432
[2] https://buildd.debian.org/status/fetch.php?pkg=p7zip&arch=sparc64&ver=15.09%2Bdfsg-1&stamp=1455411610

[my p7zip]

Please try p7zip 15.14.