* uClibc-0.9.32-2.fc15 (needed for busybox, GA version doesn't work right)

+

−

+

−

+

−

Why this list? There should not currently be any packages in stage4 that have been updated for no reason. But I still maintain that it's wrong to go for GA instead go för including updates from start. If that causes new build issues we will deal with it but I expect significantly less issues with updates than without. [[User:Hno|Hno]] 18:30, 29 September 2011 (UTC)

+

+

If a F15 update is needed to solve an ARM-related problem that exists with the GA package, simply push that update into stage4 and note this (and the reasoning) under "Completed" below. When we come to do the koji build, the stage4 SRPMs will be used as a source, so there is no need to seperately record/list the packages that had to pulled in from updates.

anaconda-15.31-2.fc15.src.rpm in stage4 is a modified package which [http://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00084.html adds an ARM screen font] (only for armv7, not for v5). It may be better to specify that ARM doesn't want a font (like S390 already). Resolution being tracked in [https://bugzilla.redhat.com/show_bug.cgi?id=743429 #743429].

−

−

== glibc ==

−

−

F15 GA version has [https://bugzilla.redhat.com/show_bug.cgi?id=708452 various failures]. Updates version is much better, we just are waiting for the solution of [https://bugzilla.redhat.com/show_bug.cgi?id=743034 bug #743034] (tzdata-update compile problem). glibc-2.14-7.arm0 (for armv5tel) includes this fix.

== zziplib ==

== zziplib ==

Line 238:

Line 231:

<pre>RPM build errors:

<pre>RPM build errors:

Directory not found by glob: /builddir/build/BUILDROOT/gdm-3.0.0-3.fc15.arm/var/lib/gdm/.gconf.mandatory/*.xml/

Directory not found by glob: /builddir/build/BUILDROOT/gdm-3.0.0-3.fc15.arm/var/lib/gdm/.gconf.mandatory/*.xml/

Fails to build on Linux 3.x host due to [https://bugzilla.redhat.com/show_bug.cgi?id=744740 #744740]. built for armv5tel on Linux 2.6 host with no problems.

+

+

== libmpc ==

+

+

GA version libmpc-0.8.3-0.3.svn855.fc15 fails to build on armv5tel, because it hits [https://bugzilla.redhat.com/show_bug.cgi?id=744589 a glibc bug where certain headers are not available on ARM] and builds with -Werror.

+

+

Pulled in version libmpc-0.8.3-0.4.svn855.fc15 from koji which avoids using -Werror.

+

+

== nss ==

+

+

GA version fails tests on ARM. nss-3.12.10-6.fc15 pulled in from F15 updates to avoid this.

+

+

GA version also fails to build on Linux 3.0 host. Updates version may or may not face the same issue - armv5tel version built on Linux 2.6 host.

+

+

== nspr ==

+

+

nspr-4.8.7-2.fc15 passes bad arguments to gcc and fails to compile. Fixed in nspr-4.8.8-4.fc15, pulled in from F15 updates.

+

+

== uClibc ==

+

+

uClibc-0.9.32-2.fc15 pulled in from F15 updates (needed for busybox, GA version doesn't work right)

+

+

== atlas ==

+

+

atlas-3.8.4-1.fc15 pulled in from F15 updates (first version with ARM support).

+

+

== libtool ==

+

+

libtool-2.4-6.fc15 was pulled in from F15 updates for armv5tel as this is the version that works alongside gcc-4.6.1.

+

+

== binutils ==

+

+

binutils-2.21.51.0.6-9.fc15 was pulled in from F15 updates to fix [https://bugzilla.redhat.com/show_bug.cgi?id=741053] (ghc and gcc build segfaults)

== coreutils ==

== coreutils ==

Line 402:

Line 405:

== mesa ==

== mesa ==

−

mesa-7.11-1.fc15 built without modification (post stage3-trim)

+

mesa-7.11-1.fc15 built without modification (post stage3-trim).

+

+

Not sure how, because the sis driver should get built, and that requires x86 or x86_64 before [https://bugzilla.redhat.com/show_bug.cgi?id=713609 #713609] produced mesa-7.11-4.fc15 (F15 updates). Anyway, if it works it works! -[[User:Dsd|Dsd]] 14:38, 8 October 2011 (UTC)

There is however mesa-dri-llvmcore left in stage3

There is however mesa-dri-llvmcore left in stage3

Line 433:

Line 438:

Additionally, the perfschema.func_mutex and perfschema.func_file_io test cases were removed as they failed during build/test time. These should be investigated and a proper fix put in place.

Additionally, the perfschema.func_mutex and perfschema.func_file_io test cases were removed as they failed during build/test time. These should be investigated and a proper fix put in place.

+

+

could not find how the test cases were disabled in the spec file. 5.5.15 fails on the same two tests. Only the valist patch is needed. The DEFAULT_HOME_ENV patch is not needed. [[User:Hno|Hno]] 14:48, 10 October 2011 (UTC)

== phonon ==

== phonon ==

Line 638:

Line 645:

</pre>

</pre>

−

For ARMv5tel (and probably v7hl too - I can't explain why these issues have not been hit or documented so far), the gcc shipped in F15 is broken (doesn't compile, and later produced bad binaries for some packages). gcc-4.6.0-9.fc15 is required to solve #697685, but gcc-4.6.1-9.fc15 is needed to fix #733549. <b>So the koji build should start with gcc-4.6.1-9.fc15 or newer.</b> Don't waste your time with older versions only to run into #697685 at the very very end of the 3 day compile process. -[[User:Dsd|Dsd]] 11:33, 24 September 2011 (UTC)

+

<b>ARMv5tel:</b> Unmodified gcc-4.6.1-9.fc15 built fine (GA version fails, this is an update to fix [https://bugzilla.redhat.com/show_bug.cgi?id=697685 #697685] and [https://bugzilla.redhat.com/show_bug.cgi?id=733549 #733549]). Needed to be bootstrapped first without cloog (trivial spec change), then libtool compiled, then cloog, then gcc(unmodified). Done successfully.

== soprano ==

== soprano ==

Line 648:

Line 655:

Built somehow with qt-docs added from f15-updates.

Built somehow with qt-docs added from f15-updates.

−

== qt ==

−

−

An updated qt-4.7.3-6.fc15 was built somehow in stage3, but the -doc package was not included.

−

−

The same version fails to build from source in stage4.

−

−

The original qt-4.7.2-8.fc15 release version fails with a problem related to mysql or openssl:

Upstream bug report: https://bugreports.qt.nokia.com//browse/QTBUG-15911 which is supposedly fixed. Confusing. Or was that only in Qt-4.8?

−

−

Others seeing same problem

−

http://developer.qt.nokia.com/forums/viewthread/7304

−

http://processors.wiki.ti.com/index.php/Building_Qt

−

http://www.qtcentre.org/threads/44311-unkown-toolchain

−

−

There is also some mention in the above bug report about Thumb2 not really being a supported platform for Qt.

−

−

Seems armv7 is not a supported platform either. Supported platforms are "Generic ARM" and "ARMv6", and ours gets detected as "Generic ARM". If QT had detected it as QT_ARHC_ARMV6 it probably would have worked. Later versions supposedly support ARMv7 as well.

Upstream bug report: https://bugreports.qt.nokia.com//browse/QTBUG-15911 which is supposedly fixed. Confusing. Or was that only in Qt-4.8?

+

+

Others seeing same problem

+

http://developer.qt.nokia.com/forums/viewthread/7304

+

http://processors.wiki.ti.com/index.php/Building_Qt

+

http://www.qtcentre.org/threads/44311-unkown-toolchain

+

+

There is also some mention in the above bug report about Thumb2 not really being a supported platform for Qt.

+

+

Seems armv7 is not a supported platform either. Supported platforms are "Generic ARM" and "ARMv6", and ours gets detected as "Generic ARM". If QT had detected it as QT_ARHC_ARMV6 it probably would have worked. Later versions supposedly support ARMv7 as well.

The issues with this package are discussed [https://www.redhat.com/archives/anaconda-devel-list/2011-October/msg00052.html here]. Needs a little upstream (anaconda team) intervention.

+

+

== anaconda ==

+

+

anaconda-15.31-2.fc15.src.rpm in stage4 is a modified package which [http://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00084.html adds an ARM screen font] (only for armv7, not for v5). It may be better to specify that ARM doesn't want a font (like S390 already). Resolution being tracked in [https://bugzilla.redhat.com/show_bug.cgi?id=743429 #743429].

+

+

== glibc ==

+

+

GA version suffers from [https://bugzilla.redhat.com/show_bug.cgi?id=708452 various failures] which are fixed by the updates version.

+

+

The armv7hl tree includes glibc-2.13.90-9.0.arm1.src.rpm with the following changes. The ones crossed out are no longer necessary in the F15 updates version.

+

* <s>Disable tests</s> - only for ease of build

+

* <s>Change make flags</s> - only for ease of build

+

* <s>Enable eabi</s> - already fixed in F15 updates

+

* glibc-arm-tzdata.patch - obsoleted by [https://bugzilla.redhat.com/show_bug.cgi?id=743034 backporting a better fix from F16] as is done in glibc-2.14-7.arm0 for armv5tel.

+

* glibc-arm-mathdefs.patch (see [https://bugzilla.redhat.com/show_bug.cgi?id=744589 #744589]) - note that this will only affect builds that run with -Werror; in the interests of moving into koji quickly, this patch could maybe be dropped for now?

Latest revision as of 11:58, 16 November 2011

We are currently engaged in bootstrap of support for armv7hl ("hardfp") ARM systems in Fedora. The purpose of this page is to track the individual status of packages (and their dependencies) that have been built for Fedora.

hno: Hmm.. have quite many packages FTBFS with "fatal error: linux/videodev.h: No such file or directory".
kwizart: hno, they need to be converted to fully support v4l2
kwizart: but the workaround is to make them built with /usr/include/libv4l1-videodev.h from libv4l-devel and make them link with -lv4l1

If a F15 update is needed to solve an ARM-related problem that exists with the GA package, simply push that update into stage4 and note this (and the reasoning) under "Completed" below. When we come to do the koji build, the stage4 SRPMs will be used as a source, so there is no need to seperately record/list the packages that had to pulled in from updates.

gesture_recog.c: In function 'compute_ols':
gesture_recog.c:142:17: error: variable 'lyy' set but not used [-Werror=unused-but-set-variable]
gesture_recog.c:141:12: error: variable 's_s' set but not used [-Werror=unused-but-set-variable]
gesture_recog.c: In function 'gesture_process':
gesture_recog.c:804:11: error: variable 'point' set but not used [-Werror=unused-but-set-variable]

uboot-tools exists in F15, build from u-boot sources. Here we should probably propose to make uboot-tools a subpackage of uboot. (If the idea is to provide u-boot images, as decision toward targeted hardware/boards is needed, references?)

Had trouble building coreutils-8.10-2.fc15 for armv5tel on koji2.laptop.org: it failed on tests/cp/fiemap-perf on "Nothing can read (much less write) that many bytes in so little time." More recent versions of coreutils fix this by skipping that test if the host filesystem is ext3 (which is the case on koji2, running Linux 3.1-rc7).

So, trying to avoid having to patch and bump coreutils in F15, I then tried to build this on an OLPC XO, which uses ext4 and runs Linux 3.0.0. This time, fiemap-perf passed but 5 gnulib readlink tests failed because the kernel returns EINVAL in a specific case where it never used to. Again, this test is fixed in more recent versions of coreutils, but in order to try and avoid patching the build, I patched in this kernel fix on my XO (still not upstream as of time of writing). The build then succeeded.

So the options for building this are:

Use a suitably old kernel (2.6.38 or older) and ext4 for the build, or

Not sure how, because the sis driver should get built, and that requires x86 or x86_64 before #713609 produced mesa-7.11-4.fc15 (F15 updates). Anyway, if it works it works! -Dsd 14:38, 8 October 2011 (UTC)

mysql-home.patch: define DEFAULT_HOME_ENV
mysql-valist_fix.patch: Use a dummy va_list for client_plugin.c

Additionally, the perfschema.func_mutex and perfschema.func_file_io test cases were removed as they failed during build/test time. These should be investigated and a proper fix put in place.

could not find how the test cases were disabled in the spec file. 5.5.15 fails on the same two tests. Only the valist patch is needed. The DEFAULT_HOME_ENV patch is not needed. Hno 14:48, 10 October 2011 (UTC)

Resulting phonon-backend-gstreamer however depends on PackageKit-gstreamer-plugin which is not yet built..??

Another possible approach would have been to make a temporary phonon-backend-gstreamer-0.0.bootstrap package that only provides "phonon(backend}". This is probably recommended way of solving this kind of user experience runtime dependencies causing circular build dependencies.

Stray /usr/lib/*.la files packaged in the binary rpm with "bad" content. These files are both developer files and did contain further references to other unpackaged .la files in the stage3 build. Rebuilt in stage4 which cleaned up the contents of the .la files a bit, but strangely kdelibs3 still fails with the same error?

Turns out the .la files is supposed to be there for kde3. And the stage4 build contains the correct files.

The failure with same error even after arts was rebuilt was caused by yum picking the wrong repository. Using the fixed yum version and it works much better.

This seems to be caused by stray .la files which have been packaged in the arts binary rpm package (not even -devel). These stray .la files is seen even on the primary arches but contents seem to differ and build there succeeds.

arts have been rebuilt in stage4 and looks better. kdelibs3 build now suceeding

ARMv5tel: Unmodified gcc-4.6.1-9.fc15 built fine (GA version fails, this is an update to fix #697685 and #733549). Needed to be bootstrapped first without cloog (trivial spec change), then libtool compiled, then cloog, then gcc(unmodified). Done successfully.

Others having the same problem reports it fixed after rebuilding raptor and soprano. Trying. Noticeable is that both raptor and soprano uses Qt4 which was just rebuilt with both different compiler flags & version.

There is an updated version which adds arm to the list of supported architectures (koji build), but not built in stage3 and never pushed as an official F15 update. The build have expired in koji and have been garbage collected.'

Running an mock build for testing. Should reach the failing point in some hours.

An interesting "hint" found in Debian:

+ ./configure --prefix=/usr `dpkg-architecture -qDEB_HOST_GNU_TYPE`
+ # * ARM: CLN's assembler support is not working properly (it was only
+ # 'theoretically' ported by copying from code that had once worked in
+ # CLISP under BSD). Same for armel.
+ # * HPPA: Assembler support is not working properly. Somebody needs to
+ # investigate but currently I don't have the inspiration for fixing
+ # things on exotic architectures.
+ # * SPARC: With some versions of GCC, there are apparently problems in
+ # passing return values in %g1.
+ case `dpkg-architecture -qDEB_HOST_ARCH` in \
+ arm|armel|hppa|sparc) \
+ ${MAKE} CPPFLAGS="-DNO_ASM" CXXFLAGS="-O2";; \
+ *) \

which is the fix for the debian bug report mentioned above. Why haven't the upstream been contacted to by default disable asm on these? This have been in Debian since 2001 (cln-1.0 something).

Depends on kdebase-workspace which depends on google-gadgets. google-gadgets is both mainline FTBFS and deprecated from F16+. There should be some hints by looking at how it's built on F16. May even be fixed by the updated versions in F15.

Alternatively convince google-gadgets to build again.

Discussed the topic with package owners. google-gadgets is dead, let it rest in piece. Rex Dieter have excluded google-gadgets on the arm platform in koji F15 build kdebase-workspace-4.6.5-6.fc15.

This requires all of KDE to be updated to 4.6.5. Downloaded to SRPMS/build/kde-4.6.5/ to be ready to queue them when kdebase is done.

Locally queued kdelibs, kdepimlibs, kdebase-workspace, kdebase, will queue the others when these are done.

Failed on kdebase-workspace again, this time due to missing libcln-devel.

ocaml has two problems: First, the spec file has armv4 instead of %{arm}. Second, the configury does not enable the "natdynlink" feature for arm, so the list of installed files doesn't match the spec file's list. I have not determined if natdynlink works for arm, so I don't know whether the configury or the spec file need changing. [dj]

Processing files: ocaml-3.12.0-5.fc15.0.arm1.armv7hl
error: File not found by glob: /builddir/build/BUILDROOT/ocaml-3.12.0-5.fc15.0.arm1.arm/usr/lib/ocaml/*.cmxs

is this from the "natdynlink" mismatch mentioned above?

Yes, the files have different names if they're not the "natdynlink" style. [dj]

To bootstrap ocaml: In a suitable build environment (i.e. not mock), rpmbuild -bc ocaml.spec. This will eventually fail, but you'll have a boot/ocamlrun binary. If you don't already have a partial ocaml RPM, you can "make install" this build; if you do have a partial ocaml RPM, you still need to copy the just-built boot/ocamlrun to /usr/bin/ocamlrun. Then rpmbuild again.

Fix ExclusiveArch in hscolour.spec and attempt rebuilding it with --nodeps.

failed. Not sure why.

./Setup configure
./Setup build
sudo ./Setup install

works however. Closer inspection of the rpmbuild output shows that it's probably profiling related. The debian install do not have profiling libs. Digging a little in /etc/rpm/ghc.macros shows there is a without_prof define.

First had problems with GCC crashing on internal error, but the reason to that was that I had forgot to activate the right swap partition after a reboot between manual build and rpmbuild steps.

Then a little overoptimisic on the mainline patchwork. It seems the patch to use system provided libffi only works on platforms where ghci is supported. A bit unfortunate as it means we will be using a bundled copy instead of the system provided one. This should be looked into.

There is also some mention in the above bug report about Thumb2 not really being a supported platform for Qt.

Seems armv7 is not a supported platform either. Supported platforms are "Generic ARM" and "ARMv6", and ours gets detected as "Generic ARM". If QT had detected it as QT_ARHC_ARMV6 it probably would have worked. Later versions supposedly support ARMv7 as well.

anaconda-15.31-2.fc15.src.rpm in stage4 is a modified package which adds an ARM screen font (only for armv7, not for v5). It may be better to specify that ARM doesn't want a font (like S390 already). Resolution being tracked in #743429.