From Fedora Project Wiki
No edit summary
No edit summary
Line 44: Line 44:
** 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.
** 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.
* 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:
** 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 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.

Revision as of 17:57, 30 October 2013

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.

Overview

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: secondary@lists.fedoraproject.org
    • System Z (s390x): s390x@lists.fedoraproject.org
    • PowerPC (ppc64): ppc@lists.fedoraproject.org
    • ARM (arm*): arm@ lists.fedoraproject.org
  • IRC channels (irc.freenode.net):
    • 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.
  • 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

ARM 32bit

ARM 64bit

IBM System Z (s390x)

IBM Power (ppc64)