From Fedora Project Wiki

Summarized information about issues on Secondary Archs in Fedora for Developers

In order to make it easier for anyone who seeks information about differences on architectures other than Intel, how to address issues that often happen either on all of them or on specific ones or to find a summarized contact information of who you can poke or go to if you have questions when you're working on a specific architecture we've created this page.


First up, if you've reached this page you're probably having either

  1. Problems building a package for a specific architecture
  2. Are looking for information about a specific architecture because you develop something on it or want to know more about it

If you are in 1) then the first part of this document should give you a good hint of what to do.

If you are in 2) then the second part of this document should give you some useful information.

Issues with package building on non x86 architectures

First of, if you should encounter a build issue on a non x86 architecture, please don't simply Exclude the arch without contacting the Secondary Arch teams first. We are a friendly group of people who do this because we enjoy other architectures and help people should they encounter issues with them.

The contact points are:

  • Mailing lists:
    • General Secondary Arch:
    • System Z (s390x):
    • PowerPC (ppc64):
    • ARM (arm*): arm@
  • IRC channels (
    • System Z (s390x): #fedora-s390x
    • PowerPC (ppc64): #fedora-ppc
    • ARM (arm*): #fedora-arm

Since Fedora 20 ARM has become a primary architecture, but in order to have all non-x86 related information in one place we will still be talking about it here and offering all the tips & tricks we have.

General problems


  • Big endian archs like ppc64 and s390x tend to show up incorrect memory handling, invalid type conversions and the like. Although ARM is able to work as big endian, in Fedora ARM is being used in little endian mode.
    • The most common thing happening then is visible memory corruption that immediately leads to segmentation faults. Unfortunately the corruption and crash often happen at different times, so debugging these failures can be really hard. On the other hand those can be really important to fix as on little endian machines like Intel these can sometimes just be so called hidden memory corruptions, where the code continues to work but the data you're continue to work with is getting garbled up more and more and potentially ruins all your data over time.

Signed/Unsigned Char type

The default signedness of the char type is implementation specific and while it is signed by default on x86, it is unsigned on arm, ppc and s390. See eg. [1] for more details.

Kernel Page Size

There are applications that expect kernel page size to be 4 KB in size. But there are architectures that support different (multiple) sizes eg. 4 KB and 64 KB and the larger one is used for performance reasons. The correct approach for the applications is to use sysconf(3) call to obtain the page size in runtime.

Atomic Primitives

Atomic primitives for multi-threaded applications are an evergreen where application authors try to prove they can still write some assembly code (or copy that from other sources) instead of using means provided by the compiler or some library. The result is an artificial limit to very narrow subset of architectures, mainly to x86/x86_64 only, sometimes ARM implementation is present, sometime 32-bit PowerPC.

Cycle counters

Precise time or cycle counting for performance measurements is another area where hand written assembly is often used. Unfortunately there is most likely no library that could be shared. Our advice is to not expect this feature is available although the CPU can support it and use some fallback solution like gettimeofday(2).

Arch unknown to the build-system

  • Architecture is unknown for configure (autofoo/libtool) as it's just been introduced.
    • This is often the case for new architectures or variantes of architectures that are not detected by autoconf and/or libtool. This then leads to the configure scripts not being able to determine whether this architecture can create shared libraries which is a very common test in configure scripts. And if that fails, the whole configure fails and the build as well. There are a few ways how you can fix this:
      • Use the latest upstream version of your component. New architectures are added to autoconf and libtool pretty quickly after they appear, so components that use autoconf or libtool with pick those new versions up when they get updated there for a new release.
      • Use %configure instead of ./configure if possible. This allows the rpmbuild process to use a macro that copies the most recent config.guess and config.sub from the autoconf package to your package, thereby allowing configure to correctly detect the arch
      • Patch your config.sub and config.guess manually or copy them yourself. Quite a bit more tedious, but does the job similarly than

ARM 32bit

ARM 64bit

IBM System Z (s390x)

IBM Power (ppc64)

Detailed differences to x86 for various architectures

These are the defaults we use in Fedora, the actual architectures and their implementation can support other options too.

ARM 32bit

  • little endian
  • char is unsigned by default

ARM 64bit

  • little endian
  •  ??? char is unsigned by default ???

IBM System Z (s390x)

  • big endian
  • only 2 GB maximum address space size in 32-bit mode
  • size_t type is unsigned long in 32-bit mode as opposed to the more common unsigned int
  • char is unsigned by default

IBM Power (ppc64)

Tips and Tricks

  • use %if %{__isa_bits} == 64 is you need to check whether the build arch is 64 bit, the common mistake is using %ifarch x86_64, but it fails on all non-x86 64-bit arches