- 1 Summarized information about issues on Secondary Archs in Fedora for Developers
- 2 Overview
- 3 Issues with package building on non x86 architectures
- 4 General problems
- 5 ARM 32bit
- 6 ARM 64bit
- 7 IBM System Z (s390x)
- 8 IBM Power (ppc64)
- 9 ARM 32bit
- 10 ARM 64bit
- 11 IBM System Z (s390x)
- 12 IBM Power (ppc64)
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
- Problems building a package for a specific architecture
- 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: firstname.lastname@example.org
- ARM (arm*): arm@ lists.fedoraproject.org
- System Z (s390x): email@example.com
- PowerPC (ppc64): firstname.lastname@example.org
- Sun SPARC (sparc): email@example.com
- 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.
- Architecture is unknown 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