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.
Problematic packages
See http://arm-temp.ausil.us/pub/fedora-arm/stage-4-failures.html for the list of pending packages that have not succeeded building
Please add notes regarding specific packages here. When completed move them down to Completed.
kdelibs
Depends on soprano-devel -> qt-docs
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:
DEBUG util.py:247: ERROR with rpm_check_debug vs depsolve: DEBUG util.py:247: openssl-devel(armv7hnl-32) is needed by mysql-devel-5.5.10-2.fc15.armv7hl DEBUG util.py:247: (1, [u'Please report this error in http://yum.baseurl.org/report'])
this may be related to the yum repository priority problem, or the mysql-devel package in stage3 is borked. But seems this error is only seen sometimes?
mysql have been rebuilt, solving the above problem.
but then fails on a build problem
../../include/QtCore/../../src/corelib/arch/qatomic_arm.h: In function 'void qt_removeObject(QObject*)': ../../include/QtCore/../../src/corelib/arch/qatomic_arm.h:361:35: error: output number 1 not directly addressable make[1]: *** [.obj/release-shared/qobject.o] Error 1
Appears to be a GCC bug? http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/1457 Khem Raj | 1 Jun 08:21
Referenced GCC patch: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01477.html commit http://gcc.gnu.org/viewcvs/trunk/gcc/expr.c?r1=171341&r2=171347&view=patch
Patches used for stage3: http://lists.fedoraproject.org/pipermail/arm/2011-September/001964.html
Patching GCC, then building qt again.
Now fails with a thumb related error
g++ -c -pipe -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DELF_INTERPRETER=\"/lib/ld-linux.so.3\" -DQLIBRARYINFO_EPOCROOT -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -o .obj/release-shared/qobject.o kernel/qobject.cpp
{standard input}: Assembler messages:
{standard input}:2878: Error: selected processor does not support Thumb mode `swp r6,r4,[r3]'
which is odd as the cpu do support thumb mode.
Upstream bug report: https://bugreports.qt.nokia.com//browse/QTBUG-15911 which is supposedly fixed. Confusing.
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 some mention about Thumb(2) not really being a supported platform for Qt.
gcc
gcc-4.6.1-4.fc15.0.arm1 patched with the patch needed for compiling ARMv7 qt.
http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/1457 Khem Raj | 1 Jun 08:21
Referenced GCC patch: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01477.html commit http://gcc.gnu.org/viewcvs/trunk/gcc/expr.c?r1=171341&r2=171347&view=patch
Wed Sep 14 23:05:27 GMT 2011 gcc-4.6.1-4.fc15.0.arm1 STARTING Thu Sep 15 02:56:11 GMT 2011 gcc-4.6.1-4.fc15.0.arm1 DONE
soprano
Depends on qt-docs (why?) which were not included in the stage3 build.
Depends on phonon -> PackageKit-gstreamer-plugin
crash
Fails on ExclusiveArch check.
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.'
Bug 734607 filed and fixed in crash-5.1.7-2 in (f17/rawhide). Update to F15 on it's way.
Update available and queued for build. https://admin.fedoraproject.org/updates/crash-5.1.7-2.fc15
emacs-vm
Locks up during build and never seems to finish, from the build.log:
+ make
make[1]: Entering directory `/builddir/build/BUILD/vm-8.1.1/lisp'
/bin/rm -f vm-autoloads.el
echo > vm-autoloads.el
(build_dir="`pwd`"; cd "."; \
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -l autoload \
-f vm-built-autoloads "/builddir/build/BUILD/vm-8.1.1/lisp/vm-autoloads.el" "`pwd`")
Building autoloads file "/builddir/build/BUILD/vm-8.1.1/lisp/vm-autoloads.el"
...
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-ps-print.el
Wrote /builddir/build/BUILD/vm-8.1.1/lisp/vm-ps-print.elc
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-reply.el
Wrote /builddir/build/BUILD/vm-8.1.1/lisp/vm-reply.elc
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-rfaddons.el
Loading vm-motion...
Loading /builddir/build/BUILD/vm-8.1.1/lisp/vm-summary.el (source)...
List of the processes:
9034 \_ rpmbuild -bb --target armv7hl --nodeps builddir/build/SPECS/emacs-vm.spec 9049 \_ /bin/sh -e /var/tmp/rpm-tmp.4lBN2i 9412 \_ make 9413 \_ /bin/sh -c for i in lisp info src pixmaps ; do (make -C $i) || exit 1; done 9414 \_ make -C lisp 9533 \_ emacs -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-rfaddons.el 9534 \_ /usr/bin/idn --quiet --idna-to-ascii --usestd3asciirules
strace shows that the process waits on a select()
[nixpanic@xo-c8-d0-04 ~]$ sudo strace -p 9533
Process 9533 attached - interrupt to quit
select(8, [7], NULL, NULL, {0, 998584}) = 0 (Timeout)
gettimeofday({1315910909, 844087}, NULL) = 0
gettimeofday({1315910909, 844409}, NULL) = 0
select(8, [7], NULL, NULL, {0, 999678}) = 0 (Timeout)
gettimeofday({1315910910, 847207}, NULL) = 0
gettimeofday({1315910910, 847810}, NULL) = 0
select(8, [7], NULL, NULL, {0, 999397}^C <unfinished ...>
Process 9533 detached
Filedescriptior 7 comes from a pipe:
lr-x------ 1 nixpanic mock 64 Sep 13 06:50 /proc/9533/fd/7 -> pipe:[1049405]
strace on the running /usr/bin/idn:
# strace -p 9534 Process 9534 attached - interrupt to quit read(0,
Bug 538874 seems to have filed for this earlier, an update to mock-1.0.0-1.fc12 was needed. Our builders seem to run mock-1.1.9-1.fc15.noarch :-/
zziplib
Mainline FTBFS Bug #716062
Fails with
echo 'Cflags: -I${includedir}' >>zzipwrap.pc
/bin/sh ../libtool --silent --tag=CC --mode=link gcc -O2 -g -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -D_USE_MMAP -Wall -Wpointer-arith
-Wsign-compare -Wmissing-declarations -Wdeclaration-after-statement
-Werror-implicit-function-declaration -Wstrict-aliasing -Warray-bounds
-Wstrict-prototypes --export-dynamic -release 0 -version-info 13:59
-thread-safe -o libzzipwrap.la -rpath /usr/lib wrap.lo ../zzip/libzzip.la
/bin/sh ../libtool --silent --tag=CC --mode=link gcc -O2 -g -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -D_USE_MMAP -Wall -Wpointer-arith
-Wsign-compare -Wmissing-declarations -Wdeclaration-after-statement
-Werror-implicit-function-declaration -Wstrict-aliasing -Warray-bounds
-Wstrict-prototypes --export-dynamic -o zzipwrap zzipwrap.o libzzipwrap.la
gcc: error: unrecognized option '--export-dynamic'
The fix is most likely simply removing the --export-dynamic flag.
mesa
<dsd_> hno: dont know if you have run into the mesa compile failure yet. just fixed in git for f14, f15 and onwards
ModemManager
in stage 3 only
Looks like it failed because of mock pty issue.
Fri Sep 16 19:06:56 GMT 2011 ModemManager-0.4-7.git20110201.fc15 START
allegro
in stage 3 only
ant
in stage 3 only
clutter-gesture
in stage 3 only
djvulibre
in stage 3 only
ecj
in stage 3 only
firebird
in stage 3 only
gc
in stage 3 only
gdm
in stage 3 only
gnome-bluetooth
in stage 3 only
gnupg
in stage 3 only
graphviz
in stage 3 only
gtkmm24
in stage 3 only
hal
in stage 3 only
icu
in stage 3 only
java-1.5.0-gcj
in stage 3 only
java-1.6.0-openjdk
in stage 3 only
jpackage-utils
in stage 3 only
kernel
in stage 3 only
ksh
in stage 3 only
libdc1394
in stage 3 only
libffado
in stage 3 only
libgphoto2
in stage 3 only
libproxy
in stage 3 only
libtirpc
in stage 3 only
libvpx
in stage 3 only
llvm
in stage 3 only
mesa
in stage 3 only
ocaml
in stage 3 only
perl-Coro
in stage 3 only
perl-Tk
in stage 3 only
pinentry
in stage 3 only
postgresql
in stage 3 only
ppl
in stage 3 only
pulseaudio
in stage 3 only
qt
in stage 3 only
rrdtool
in stage 3 only
systemtap
in stage 3 only
tcl
in stage 3 only
u-boot
in stage 3 only
upower
in stage 3 only
usermode
in stage 3 only
uuid
in stage 3 only
w3m
in stage 3 only
xalan-j2
in stage 3 only
xerces-j2
in stage 3 only
xml-commons-apis
in stage 3 only
xml-commons-resolver
in stage 3 only
zenity
in stage 3 only
Completed
These packages have completed a full build with some manual actions
PackageKit
Required changing src/pk-main.c to check version glib version 2,29,4 instead of 2,28,7. This later version is where glib-unix.h begins getting installed by glib2-devel.
xulrunner
xulrunner-2.0.1-1.fc15 failed with
checking size of int *... 0 configure: error: Unexpected pointer size
Fixed by https://bugzilla.redhat.com/show_bug.cgi?id=738509
Is *not* this upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=626035
mysql
mysql-5.5.14-2.fc15.0.arm1 was built with 2 patches from stage3:
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.
phonon
Have a circular dependency on it's backend providers. Main phonon package have been built but can not be installed as there is no backend providers, and blocks the backend providers from being built.
As the main package is already in stage4 the normal boostrap procedure of temporarily removing dependencies do not work well.
Trying alternative dependency override by manually installing phonon using rpm
rm rpms/phonon-backend-gstreamer-4.5.1-1.fc15/*.log mock -r fedora-15-armhfp --init --no-cleanup-after --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ mock -r fedora-15-armhfp --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ --installdeps rpms/phonon-4.5.0-2.fc15/phonon-4.5.0-2.fc15.src.rpm mock -r fedora-15-armhfp --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ --copyin rpms/phonon-4.5.0-2.fc15/phonon-4.5.0-2.fc15.armv7hl.rpm builddir/ mock -r fedora-15-armhfp --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ --chroot "rpm -i builddir/phonon-4.5.0-2.fc15.armv7hl.rpm --nodeps" mock -r fedora-15-armhfp --no-clean --no-cleanup-after --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ SRPMS/phonon-backend-gstreamer-4.5.1-1.fc15.src.rpm
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.
systemtap-sdt
Was build in stage3 somehow.
Depends on crash-devel, which fails on ExclusiveArch check.
There is an update koji build which removes the dependency on crash. Now scheduled for build. First attempts crashed for unknown reasons, but after rescheduling it again it seems to be building.
Worked fine this time.
arts
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.
kdelibs3
kdelibs3 in F15 is FTBFS.
There is an updated kdelibs3-3.5.10-28.fc15 in which did succeed building in koji. This was never pushed as an update however and have already been cleaned by the koji garbage collector
Even the updated version fails to build on ARM but now with the following error
/bin/sh ../../libtool --silent --tag=CXX --mode=link g++ -DNDEBUG -DNO_DEBUG -O2 -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -L/usr/lib/qt-3.3/lib -Wl,--as-needed -Wl,--enable-new-dtags -no-undefined -version-info 3:0:2 -o libartskde.la -rpath /usr/lib libartskde_la.all_cc.lo libartskde_la.all_cpp.lo ../../kio/libkio.la -lqtmcop -lsoundserver_idl grep: /usr/lib/libgmodule-2.0.la: No such file or directory /bin/sed: can't read /usr/lib/libgmodule-2.0.la: No such file or directory make[3]: Leaving directory `/builddir/build/BUILD/kdelibs-3.5.10/arts/kde'
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
libSM
FTBFS in F15. No fixed package available.
Patched in stage3
Reworked the patch a little and added to FTBFS bug #660819
Some further investigation and it's actually xmlto that is broken causing FTBFS here and in a number of other packages. xmlto Bug #681909
Compiles fine with updated/fixed xmlto.
sqlite
sqlite-3.7.5-3 fails in several selftests
it is built in stage3 somehow but there is no SRPM or spec file available on arm-temp so can't tell how.
there is a newer -5 build in koji by pbrobinson, disabling self tests on arm, but never pushed as an update and have been garbage collected. Regenerated from git.
Should investigate with upstream why those selftests fail. Also check a more current version.
Wed Sep 14 11:58:30 GMT 2011 sqlite-3.7.5-5.fc15 STARTING Wed Sep 14 12:41:56 GMT 2011 sqlite-3.7.5-5.fc15 DONE
gettext
Needs a patch and spec file update for new kernel & gnulib.
gettext-0.18.1.1-7.fc15.0.arm1
Not sure if the changes have been upstreamed.
m4
Needs a patch and spec file update for new kernel & gnulib.
m4-1.4.16-1.fc15.0.arm1
Not sure if the changes have been upstreamed.