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.
See http://arm-temp.ausil.us/pub/fedora-arm/stage-4-failures.html for the list of pending packages that have not succeeded building
See http://djdelorie.fedorapeople.org/armv7-srpms.html for a report on the differences to mainline
Known F15 issues
linux/videodev.h
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
Updates packages to build directly into ARM GA
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.
Needed for koji (jcm)
java-1.5.0-gcj
java-1.6.0-openjdk
pki-core
DEBUG util.py:247: Error: No Package found for osutil
osutil fails on some java related
-- Found Java: /usr/bin/java CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): Could NOT find JNI (missing: JNI_LIBRARIES JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY)
sinjdoc
fails on java related issues
checking for java... java checking for a jsr-14-compliant java 1.4 compiler... not-found configure: error: Can't find tools to build java programs.
gtkmm24
Tracked below. Seems to be FTBFS after glibmm24 packaging change.
busybox
done. busybox-1.18.2-5.fc15 pulled in from updates (earlier versions don't compile on ARM)
docbook2X
Depends on perl(XML::LibXML::Common), perl(XML::LibXML)
done.
icu
done
llvm
depends on ocaml. See below.
done
pax
Done. pax-3.4-10.fc12 in F15 GA is broken - trivial gcc compile error. Use pax-3.4-12.fc15 instead.
perl-XML-LibXML
Depends on itself, probably in rpm triggers. Trying with a dummy bootstrap package just providing the needed provides.
perl-XML-LibXML-0.0.bootstrap
worked fine. Done.
uuid
Done. uuid-1.6.2-4.fc15 in F15 GA is broken - trivial spec error. Use uuid-1.6.2-5.fc15 instead.
xerces-c
calls dos2unix with bad arguments. Seems to have been failing for some time but appears dos2unix did not exit with an error and only an error message before.
seems fixed in F16, but also a newer version.
trying build with corrected dos2unix arguments (-k instead of -U) Hno 10:40, 23 September 2011 (UTC)
Done. fixed in xerces-c-3.0.1-22.fc15
Self & Circular dependencies
These packages have circular dependencies on themselves
erlang-R14B
fpc
mlton
vinagre
mono
perl-Math-Random-MT-Auto
sbcl
eclipse icu4j
simple circular dependency - djdelorie working on bootstrapping
ghc ghc hscolour hscolour
done. ghc needs a manual bootstrap.
See ghc below
java java ecj
log4net nant
step 1: build nant in bootstrap mode: http://koji.fedoraproject.org/koji/buildinfo?buildID=238337
step 2: build log4net using the nant built in step 1: http://koji.fedoraproject.org/koji/buildinfo?buildID=238941
step 3: build nant without bootstrap mode: http://koji.fedoraproject.org/koji/buildinfo?buildID=238948
plplot perl-PDL-Graphics-PLplot
valgrind plpa openmpi
Problematic packages
Please add notes regarding specific packages here. When completed move them down to Completed.
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.
allegro
in stage 3 only. allegro-4.2.3-5.fc15.src.rpm
stage4 allegro-4.2.3-5.fc15 failure:
gcc -DALLEGRO_MODULES_PATH=\"/usr/lib/allegro\" -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -pthread -I/usr/include/kde/artsc -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DALLEGRO_NO_ASM -DALLEGRO_LIB_BUILD -O2 -funroll-loops -ffast-math -Wall -Wno-unused -x assembler-with-cpp -c ./src/x/xdga2s.s -o obj/unix/shared/alleg/xdga2s.o ./src/x/xdga2s.s: Assembler messages: ./src/x/xdga2s.s:54: Error: junk at end of line, first unrecognized character is `,'
clutter-gesture
available in stage3 only, NO SOURCES!
mainline FTBFS
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]
ecj
in stage 3 only
No obvious error in logs. Ends when calling ant. Rescheduled for build.
Failed with the same unobvious error.
+ ant org.apache.tools.ant.helper.ProjectHelper2 RPM build errors:
firebird
in stage3 only
../src/include/../common/classes/fb_atomic.h:518:2: error: #error AtomicCounter: implement appropriate code for your platform!
source available in stage3. Is there a patch?
firefox
firefox-6 fails to build because -mfloat-abi=softfp is hard-coded in configure. Possible patches in the Mozilla Bugzilla
gdm
in stage 3 only
RPM build errors:
Directory not found by glob: /builddir/build/BUILDROOT/gdm-3.0.0-3.fc15.arm/var/lib/gdm/.gconf.mandatory/*.xml/
gtkmm24
in stage3 only. gtkmm24-2.24.0-3.fc15.src.rpm pandaboard2.znjan.st
/usr/bin/perl -- "/usr/share/glibmm-2.4/doctool/doc-install.pl" --verbose --mode=0644 -l 'libsigc++-2.0.tag@../../../libsigc++-2.0/reference/html/' -l 'glibmm-2.4.tag@../../../glibmm-2.4/reference/html/' -l 'cairomm-1.0.tag@../../../cairomm-1.0/reference/html/' -l 'pangomm-1.4.tag@../../../pangomm-1.4/reference/html/' -l 'atkmm-1.6.tag@../../../atkmm-1.6/reference/html/' -t '/builddir/build/BUILDROOT/gtkmm24-2.24.0-3.fc15.arm/usr/share/doc/gtkmm-2.4/reference/html' --glob -- 'reference/html/*.css' 'reference/html/*.gif' 'reference/html/*.html' 'reference/html/*.png' Can't open perl script "/usr/share/glibmm-2.4/doctool/doc-install.pl": No such file or directory
broken glibmm-2.4 package during build?
No, there is no package providing "/usr/share/glibmm-2.4/doctool/doc-install.pl" in F15 any longer.
Filed a package F15 FTBFS bug.
kernel
in stage 3 only
well, there is a kernel in stage4 also, but not the ones we are using.
libdc1394
in stage 3 only
dc1394_vloopback.c:49:28: fatal error: linux/videodev.h: No such file or directory
same error as in hal.
libgphoto2
in stage 3 only
Being fixed mainline in Bug #745081
libvpx
in stage 3 only
perl-Coro
in stage 3 only
perl-Tk
in stage 3 only
rrdtool
in stage 3 only
u-boot
in stage3 only
do not exists in F15.
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?)
w3m
in stage 3 only
xalan-j2
in stage 3 only
gtksourceview2
Mainline FTBFS with patches available but seems the maintainers are not responding.
Completed
These packages have completed a full build with some manual actions
python3
GA version: 3 tests fail on ARM (#744624).
Fixed in latest version from koji: python3-3.2-3.fc15
pth
Fails to build on Linux 3.x host due to #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 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 [1] (ghc and gcc build segfaults)
coreutils
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
- Patch the build system kernel and run the build on ext4, or
- Add this coreutils fix and this gnulib fix to F15 coreutils and build that instead, which solves/avoids both the ext3 and readlink problems.
findutils
findutils includes gnulib so the readlink test failures noted in the coreutils section above apply exactly. findutils-4.5.9-3.fc15 built for armv5tel on OLPC XO with a patched kernel.
xerces-j2
in stage 3 only
zenity
in stage 3 only
usermode
in stage 3 only
tcl
in stage 3 only
ksh
in stage 3 only
systemtap
in stage 3 only
libtirpc
in stage 3 only
upower
upower-0.9.12-1.fc15 built without modification (post stage3-trim)
pinentry
pinentry-0.8.1-4.fc15 built without modification (post stage3-trim)
mesa
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 #713609 produced mesa-7.11-4.fc15 (F15 updates). Anyway, if it works it works! -Dsd 14:38, 8 October 2011 (UTC)
There is however mesa-dri-llvmcore left in stage3
gnome-bluetooth
gnome-bluetooth-3.0.1-1.fc15 built without modification (post stage3-trim)
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.
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)
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
Mainline FTBFS with kernel update. Needs a patch and spec file update for new kernel & gnulib. https://bugzilla.redhat.com/show_bug.cgi?id=739188
gettext-0.18.1.1-7.fc15.0.arm1
m4
Mainline FTBFS with kernel update. Needs a patch and spec file update for new kernel & gnulib. https://bugzilla.redhat.com/show_bug.cgi?id=739189
m4-1.4.16-1.fc15.0.arm1
ModemManager
Failed because of mock pty issue. Rebuilt with fixed mock.
djvulibre
in stage3 only, NO SOURCES!
mainline FTBFS. Fixed in djvulibre-3.5.22-2.fc15.src.rpm update.
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 :-/
Built fine on trimslice with mock-1.1.12.fc15.noarch
gnupg
in stage3 only
pty failure. Rescheduled.
Built fine with mock-1.1.12.fc15.noarch
gcc
current:
gcc-4.6.1-9.fc15.0.arm1 is currently building. Changes in the 0.arm1 version:
build_libstdcxx_docs disabled
Addition of gcc46-java-natclass.patch and gcc46-libjava.patch for java support.
Addition of gcc-expr.c-171347.patch for volatile bitfield correctness.
Define _gnu to -gnueabi for arm arch.
Debuginfo infrastructure removed from spec file.
%check disabled
No libgtkpeer.so libgjsmalsa.so or libjawt.so generated.
previously:
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
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.
soprano
Depends on qt-docs (why?) which were not included in the stage3 build.
Depends on phonon -> PackageKit-gstreamer-plugin
Built somehow with qt-docs added from f15-updates.
kdelibs
qt is in stage3, and qt-docs have been copied from noarch.
Fri Sep 16 21:50:47 GMT 2011 kdelibs-4.6.2-5.fc15 STARTING
failed with a thumb error
cd /builddir/build/BUILD/kdelibs-4.6.2/armv7hl-redhat-linux-gnueabi/kdecore && /usr/bin/c++ -DMAKE_KDECORE_LIB -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=21 -DQT_NO_CAST_FROM_ASCII -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Werror=return-type -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -O2 -DNDEBUG -DQT_NO_DEBUG -fPIC -I/builddir/build/BUILD/kdelibs-4.6.2/armv7hl-redhat-linux-gnueabi/kdecore -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore -I/builddir/build/BUILD/kdelibs-4.6.2 -I/builddir/build/BUILD/kdelibs-4.6.2/armv7hl-redhat-linux-gnueabi -I/builddir/build/BUILD/kdelibs-4.6.2/interfaces -I/builddir/build/BUILD/kdelibs-4.6.2/armv7hl-redhat-linux-gnueabi/kdecore/network -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/sonnet -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/auth -I/builddir/build/BUILD/kdelibs-4.6.2/kjs -I/builddir/build/BUILD/kdelibs-4.6.2/armv7hl-redhat-linux-gnueabi/kjs -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/compression -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/config -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/date -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/io -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/jobs -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/kernel -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/network -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/services -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/localization -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/sycoca -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/text -I/builddir/build/BUILD/kdelibs-4.6.2/kdecore/util -I/usr/include/QtCrypto -I/usr/include/polkit-qt-1 -I/usr/include/phonon -I/usr/include/QtXmlPatterns -I/usr/include/QtXml -I/usr/include/QtWebKit -I/usr/include/QtUiTools -I/usr/include/QtTest -I/usr/include/QtSvg -I/usr/include/QtSql -I/usr/include/QtScriptTools -I/usr/include/QtScript -I/usr/include/QtOpenGL -I/usr/include/QtNetwork -I/usr/include/QtMultimedia -I/usr/include/QtHelp -I/usr/include/QtDesigner -I/usr/include/QtDeclarative -I/usr/include/QtDBus -I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore -I/usr/include/Qt -I/usr/lib/qt4/mkspecs/default -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o CMakeFiles/kdecore.dir/kernel/kcomponentdata.o -c /builddir/build/BUILD/kdelibs-4.6.2/kdecore/kernel/kcomponentdata.cpp /tmp/cctYKKvz.s: Assembler messages: /tmp/cctYKKvz.s:143: Error: selected processor does not support Thumb mode `swp r2,r3,[r7]' /tmp/cctYKKvz.s:506: Error: selected processor does not support Thumb mode `swp r2,r3,[r7]' /tmp/cctYKKvz.s:991: Error: selected processor does not support Thumb mode `swp r2,r3,[r8]' /tmp/cctYKKvz.s:1380: Error: selected processor does not support Thumb mode `swp r2,r3,[r8]'
This is actually QT failing. Need to solve QT first. include/QtCore/qatomic_arm.h
QT have been rebuilt in stage4. Now fails on something soprano related.
cd /builddir/build/BUILD/kdelibs-4.6.2/armv7hl-redhat-linux-gnueabi/nepomuk && /usr/bin/onto2vocabularyclass --name NDO --encoding trig --namespace Nepomuk::Vocabulary --export-module nepomuk /usr/share/ontology/nepomuk/ndo.trig (Soprano::PluginManager) found no soprano plugin at "/usr/lib/soprano/libsoprano_raptorparser.so" (Soprano::PluginManager) found no soprano plugin at "/usr/lib/soprano/libsoprano_nquadparser.so" Could not find parser plugin for encoding trig make[2]: *** [nepomuk/ndo.h] Error 1
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.
soprano & raptor rebuilt. New kdelibs build running.
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
More issues of the same kind detected. Bug 734607 updated with new arm patch.
crash-5.1.7-2.0.arm1 queued for build. Should build fine this time (verified in an unclean mock run)
libopensync
FTBFS in F15.
Should be fixed in libopensync-0.22-9.fc15 but that build was never pushed as an update and have been garbage collected.
Recreated from git.
kdnssd-avahi
kdnssd-avahi-0.1.3-0.11.20080116svn.fc15.src
Circular dependency kdelibs3-devel requires libkdnssd-devel, and kdnssd-avahi (provides libkdnssd-devel) buildrequires kdelibs3-devel.
Attempting bootstrap by providing a dummy kdnssd-avahi which provides libkdnssd-devel. kdnssd-avahi-0.0-1.bootstrap
kdnssd-avahi-0.1.3-0.11.20080116svn.fc15.src now building. Maybe some other kdelibs3 packages as well but lets about those later. Most likely their builds will just fail if really needing kdnssd.
Failed on missing include, which is bad as then there is a circular dependency where xdnssd-avahi gets built using parts of older self.
creating libkdnssd_la.all_cpp.cpp ...
/bin/sh ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include/kde -I/usr/lib/qt-3.3/include -I. -D_REENTRANT -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/usr/lib/qt-3.3/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -DNO_DEBUG -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -c -o libkdnssd_la.all_cpp.lo libkdnssd_la.all_cpp.cpp
In file included from remoteservice.cpp:35:0,
from libkdnssd_la.all_cpp.cpp:2:
remoteservice.h:25:31: fatal error: dnssd/servicebase.h: No such file or directory
compilation terminated.
Fixing the package to build using it's own headers by adding "ln -s . kdnssd-avahi/dnssd" to %prep
PyQt4 <-> qscintilla
There is a circular build dependency between PyQT4 and qscintilla
DEBUG util.py:247: Getting requirements for PyQt4-4.8.3-2.fc15.src DEBUG util.py:247: --> chrpath-0.13-7.fc15.armv7hl DEBUG util.py:247: --> 1:dbus-devel-1.4.6-4.fc15.armv7hl DEBUG util.py:247: --> dbus-python-devel-0.83.0-8.fc15.armv7hl DEBUG util.py:247: --> Already installed : 1:findutils-4.5.9-3.fc15.armv7hl DEBUG util.py:247: --> phonon-devel-4.5.0-2.fc15.armv7hl DEBUG util.py:247: Error: No Package found for qscintilla </pre <pre> DEBUG util.py:247: Getting requirements for qscintilla-2.4.6-2.fc15.src DEBUG util.py:247: --> 1:qt-devel-4.7.3-6.fc15.armv7hl DEBUG util.py:247: Error: No Package found for PyQt4-devel >= 4.7
Not in a mood to try to investigate which can in theory be built without the other. Package owners mailed asking for advice.
Rex Dieter responded quickly, informing that qscintilla SRPM have a bootstrap mode by defining python to 0. A qscintilla-2.4.6-0.0.bootstrap.fc15.src package successfully built with this change.
cln
Fails linking it's own exaples
/bin/sh ../libtool --tag=CXX --mode=link g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -o pi pi.o ../src/libcln.la -lgmp libtool: link: g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -o .libs/pi pi.o ../src/.libs/libcln.so -lgmp ../src/.libs/libcln.so: undefined reference to `copy_loop_down' ../src/.libs/libcln.so: undefined reference to `_divu_32_rest' ../src/.libs/libcln.so: undefined reference to `divu_6432_3232_' ../src/.libs/libcln.so: undefined reference to `clear_loop_up'
Searching for the same error locates an ancient Debian bug report from 2001 with the same symptoms. Debian Bug #94097. Unfortunately no hints at all to how it was fixed or what was causing it.
armv5tel also fails with the same error. armv5tel cln-1.3.1-1.fc13 failed build
Builds fine in x86_64 F15 with updates however.
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).
Oh well.. it's reported all right.. INSTALL says
CLN is known to work with: ========================= - Linux/x86, gcc-3.x, gcc-4.[0-5].x - Linux/x86_64, gcc-3.[3-4], gcc-4.[0-6].x, clang-2.8 - Linux/ia64, gcc-3.[2-4], gcc-4.[0-4].x - Linux/arm, gcc-3.[0-3] (*), gcc-4.[0-4].x (*) - Linux/mips, gcc-3.3, gcc-4.[0-4].x - Linux/sparc, gcc-3.[1-3], gcc-4.[0-2].x - Linux/alpha, gcc-3.[0-3], gcc-4.[0-2].x - Linux/powerpc, gcc-3.[0-3], gcc-4.[0-4].x - Linux/hppa, gcc-4.2.x (*) - Solaris 2.4 (sparc), gcc-3.[1-3], gcc-4.[0-2].x (*) - OSF/1 V4.0 (alpha), gcc-3.1 - Irix 6.5, gcc-3.0 - OS X Leopard (x86), gcc 4.0.1 - Windows/32-bit, MSVC 16.00.30319.01 (*) On these platforms, problems with the assembler routines have been reported. It may be best to add "-DNO_ASM" to CPPFLAGS before configuring.
which almost matches Debian. The list above do not indicate known problems on linux/sparc, only solaris (sparc).
foomatic
Depends on itself.
Nicely commented in the spec how to bootstrap.
bootstrap version queued & built.
full version queued, but probably depends on other stuff as well not built yet.
seems to have built fine.
kdebase
KDE Core Applications
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.
kdebase-workspace cooking again after builddeps resolved.
Wed Sep 21 14:09:32 GMT 2011 kdebase-workspace-4.6.5-6.fc15 STARTING
Still problems. Fixed in git but no new koji build.
kdebase-workspace-4.6.5-6.fc15-1b246a82133359fcc4364d8a18564fd47081fc6e
icu
in stage 3 only. icu-4.4.2-7.fc15.src.rpm panda01.ausil.us
uconvmsg/uconvmsg_dat.s: Assembler messages: uconvmsg/uconvmsg_dat.s:2: Error: junk at end of line, first unrecognized character is `,' uconvmsg/uconvmsg_dat.s:5: Error: unrecognized symbol type ""
4.4.2-8 should fix this. queued for build.
postgresql
was in stage 3 only. Now built somehow.
ppl
in stage 3 only
Trying to build without gprolog. gprolog is ExclusiveArch: x86_64 %{ix86} ppc alpha.
Same ExclusiveArch already in git. http://koji.fedoraproject.org/koji/buildinfo?buildID=245759
queued for build
gc
in stage3 only, NO SOURCES, only original src.rpm from F15 (fc13)
mainline FTBFS.
Stage4 FTBFS (ARM specific):
gcc -DHAVE_CONFIG_H -I. -fPIC -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -DNDEBUG -c atomic_ops_stack.c /tmp/ccqMX8vM.s: Assembler messages: /tmp/ccqMX8vM.s:70: Error: thumb conditional instruction should be in IT block -- `strexeq r4,r1,[r3]'
Rebuilt fine after thumb mode was disabled in redhat-rpm-macros.
Why is it mainline FTBFS then?
llvm
in stage 3 only
Requires a rebuilt ocaml (ocaml in stage3 is missing /usr/bin/ocamlrun). [dj]
Rebuilt fine after ocaml was fixed. No arm specific changes.
ocaml
in stage 3 only
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]
depends on itself but hopefully the copy in stage3 will do fine.
Running a build with %{arm}. Hno 07:34, 23 September 2011 (UTC)
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.
ghc
ghc needs ghc to build, but we do not have ghc..
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting documents the bootstrapping procedure, but in ghc-7.0.2 bootstraping procedure seems completely broken.
Debian do have ghc-7.0.4 arm hardfloat. will try using that as initial compiler.
http://http.debian-ports.org/debian/pool-armhf/main/g/ghc/
also needs libgmp10 från http://http.debian-ports.org/debian/pool-armhf/main/g/gmp/
after manual installation and library location fixup, finish ghc installation by running:
ghc-pkg recache --global
and replace /usr/bin/ghc with a small wrapper to work around implicit DSO issues relating to pthread
#!/bin/sh exec /usr//lib/ghc/bin/ghc "$@" -lpthread
Fix ExclusiveArch in ghc.spec and unpack sources by rpmbuild -bp ghc.spec --nodeps
Install as many of the dependencies as possible.
Build it:
./configure make
seems get started. May even work as rpm. Aborting to retry using rpm.
testbuild of hscolour
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.
rpmbuild -ba hscolour.spec --nodeps -D"without_prof 1" -D"without_haddock 1" -D"without_hscolour 1" sudo rpm -i ../RPMS/armv7hl/hscolour-1.17-8.fc15.0.arm1.armv7hl.rpm rpmbuild -ba hscolour.spec --nodeps -D"without_prof 1" -D"without_haddock 1"
looks good. So it's possible to bootstrap this package fully using rpm.
native ghc
rpmbuild -ba ghc.spec --nodeps
failed.. needing some overrides. Reverting to begin with a manual build again. Done.
ghc-7.0.2 for Fedora now available as .tar.gz. Will clean out the build root and continue bootstraping with only this installed, pruning out the remains of the foreign Debian version.
rpmbuild of ghc & hscolour
Starting from a clean buildroot.
buildroot setup:
mock -r fedora-15-armhfp --result $PWD --init rpm -q --requires -p ghc-7.0.2-16.3.fc15.0.arm1.src.rpm ghc ghc-rpm-macros >= 0.11.12 gmp-devel libffi-devel ghc-directory-devel ghc-process-devel ghc-pretty-devel ghc-containers-devel ghc-haskell98-devel ghc-bytestring-devel ncurses-devel libxslt docbook-style-xsl hscolour rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 mock -r fedora-15-armhfp --result $PWD --install gmp-devel libffi-devel ncurses-devel libxslt docbook-style-xsl ghc-rpm-macros mock -r fedora-15-armhfp --result /home/henrik/ghc --copyin ghc-7.0.2-norpm.tar.gz ghc-7.0.2-16.3.fc15.0.arm1.src.rpm hscolour-1.17-8.fc15.0.arm1.src.rpm /builddir/
then building hscolour
mock -r fedora-15-armhfp --result $PWD --chroot "tar zxf builddir/ghc-7.0.2-norpm.tar.gz" mock -r fedora-15-armhfp --result $PWD --unpriv 'rpmbuild --rebuild builddir/hscolour-1.17-8.fc15.0.arm1.src.rpm --nodeps -D"without_prof 1" -D"without_hscolour 1"' mock -r fedora-15-armhfp --result $PWD --copyout /builddir/build/RPMS/* . mock -r fedora-15-armhfp --result $PWD --chroot "rpm -i /builddir/build/RPMS/*hscolour* --nodeps"
and finally a full native build of ghc
mock -r fedora-15-armhfp --result $PWD --unpriv --chroot 'rpmbuild --rebuild builddir/ghc-7.0.2-16.3.fc15.0.arm1.src.rpm --nodeps'
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.
mock -r fedora-15-armhfp --result $PWD --init mock -r fedora-15-armhfp --result $PWD --install gmp-devel libffi-devel ncurses-devel libxslt docbook-style-xsl ghc-rpm-macros mock -r fedora-15-armhfp --result $PWD --copyin ghc-7.0.2-norpm.tar.gz *.rpm /builddir/ mock -r fedora-15-armhfp --result $PWD --chroot "tar zxf builddir/ghc-7.0.2-norpm.tar.gz" mock -r fedora-15-armhfp --result $PWD --chroot "rpm -iv /builddir/*hscolour*armv7hl.rpm --nodeps"
mock -r fedora-15-armhfp --result $PWD --unpriv --chroot 'rpmbuild --rebuild builddir/ghc-7.0.2-16.3.fc15.0.arm3.src.rpm --nodeps'
failed after 13 hours due to a stupid ghc.spec error of mine %{without where i meant %{with
mock -r fedora-15-armhfp --result $PWD --unpriv --chroot 'rpmbuild --rebuild builddir/ghc-7.0.2-16.3.fc15.0.arm4.src.rpm --nodeps'
finished.
result uploaded to stage3, and srpms sent to the build farm for clean mock builds.
ExlusiveArch on ghc related packages also updated to include armv7hl to try to shake out which packags build on armv7hl and which needs more attention.
mainline merge
Work is progressing together with mainline package owner juhp to integrate the arm changes mainline, starting with ghc and then the other packages. Hno 12:48, 30 September 2011 (UTC)
main ghc package changes have been merged mainline. Still remains to address all the other packages where armv7hl have been added as supported arch. Hno 02:03, 6 October 2011 (UTC)
speedcrunch
had issues with unsigned char. See Bug #736873. Fixed in fixed in speedcrunch-0.11-0.3.alpha.fc15
gypsy
patched to build with gcc 4.6. Tracked in Bug #734261.
pl
pl-5.10.2-5.fc15.0.arm1 patched to use correct java paths on arm.
pl-5.10.5-4.fc17 builds without patches, but that's rawhide and not f15.
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. 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.
Configure flags needed: -arch armv6 -no-neon
Also need the Thumb2 patch from QTBUG-16402 fix ARM Thumb2 build https://qt.gitorious.org/qt/qt/merge_requests/1121
Alternatively enable "-Wa, -mimplicit-it=thumb" in rpmrc letting GAS automatically adjust ARM assembly code for Thumb mode.
All changes merged mainline in qt-4.7.4-3.fc15
python-pyblock
python-pyblock-0.49-2.fc15 is arm patched, remowing -Wall for unknown reason.
The issues with this package are discussed here. Needs a little upstream (anaconda team) intervention.
anaconda
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.
glibc
GA version suffers from 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.
Disable tests- only for ease of buildChange make flags- only for ease of buildEnable eabi- already fixed in F15 updates- glibc-arm-tzdata.patch - obsoleted by backporting a better fix from F16 as is done in glibc-2.14-7.arm0 for armv5tel.
- glibc-arm-mathdefs.patch (see #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?
- glibc-arm-clone-unwind.patch - solves something java-related, see #749556
hal
in stage3 only, hal-0.5.14-6.fc15.src.rpm pandaboard2.znjan.st
gcc -DHAVE_CONFIG_H -I. -I../../.. -DPACKAGE_SYSCONF_DIR=\""/etc"\" -DPACKAGE_DATA_DIR=\""/usr/share"\" -DPACKAGE_BIN_DIR=\""/usr/bin"\" -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -DPACKAGE_LOCALSTATEDIR=\""/var"\" -I../../.. -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/blkid -I/usr/include/uuid -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -Wall -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -c probe-video4linux.c probe-video4linux.c:33:28: fatal error: linux/videodev.h: No such file or directory
kernel-headers issue? There is videodev2.h, but not videodev.h
there is no videodev2.h on x86_64 either.
Mainline FTBFS.
Patch available upstream in http://cgit.freedesktop.org/hal/commit/?id=ae13d96fa2a0612b6000f4b8f6ed9d3564035703 which depends on http://cgit.freedesktop.org/hal/commit/?id=8f624253f0135ca77a893ad4e8168f51ef90d4da
java-1.5.0-gcj
in stage 3 only
java-1.6.0-openjdk
in stage 3 only
graphviz
in stage3 only. graphviz-2.26.3-4.fc15.src.rpm pandaboard2.znjan.st.
specfile syntax FTBFS.
error: types must match error: /builddir/build/SPECS/graphviz.spec:156: parseExpressionBoolean returns -1
got fixed mainline.
Packages Needing ARM Patches Upstreamed
These packages have built on ARMv5tel and ARMv7hl and need to have patches upstreamed.
Procedure:
- When you start working on a particular package, put your nick after the package in parenthesis
- When the package patches are upstreamed, cross out the package name using
strikeout. - Add any comments with a sub-bullet (#*)
Package list:
- anaconda-15.31-1.fc15.0.arm1
cln-1.3.1-2.fc15.0.arm2pbrobinson (in 1.3.2-1 all releases)crash-5.1.7-2.fc15.0.arm1pbrobinson- gcc-4.6.1-4.fc15.0.arm2
- gcc-4.6.1-9.fc15.0.arm1
- gettext-0.18.1.1-7.fc15.0.arm1
- ghc-ansi-terminal-0.5.5-3.fc15.0.arm1
- ghc-attempt-0.3.0-4.fc15.0.arm1
- ghc-attoparsec-0.8.5.0-3.fc15.0.arm1
- ghc-base64-bytestring-0.1.0.2-2.fc15.0.arm1
- ghc-binary-0.5.0.2-8.fc15.0.arm1
- ghc-binary-shared-0.8.1-2.fc15.0.arm1
- ghc-Boolean-0.0.1-7.fc15.0.arm1
- ghc-bytestring-nums-0.3.2-3.fc15.0.arm1
- ghc-bytestring-trie-0.2.3-2.fc15.0.arm1
- ghc-cereal-0.3.0.0-1.fc15.1.0.arm1
- ghc-cgi-3001.1.7.4-6.fc15.0.arm1
- ghc-chalmers-lava2000-1.1.1-11.fc15.0.arm1
- ghc-cmdargs-0.6.8-2.fc15.0.arm1
- ghc-csv-0.1.2-8.fc15.0.arm1
- ghc-dataenc-0.14-1.fc15.0.arm1
- ghc-deepseq-1.1.0.2-4.fc15.0.arm1
- ghc-digest-0.0.0.8-4.fc15.0.arm1
- ghc-editline-0.2.1.0-23.fc15.0.arm1
- ghc-failure-0.1.0.1-4.fc15.0.arm1
- ghc-fgl-5.4.2.3-5.fc15.0.arm1
- ghc-ghc-paths-0.1.0.8-6.fc15.0.arm1
- ghc-GLUT-2.1.2.1-9.fc15.0.arm1
- ghc-hashed-storage-0.5.5-2.fc15.0.arm1
- ghc-haskeline-0.6.3.2-5.fc15.0.arm1
- ghc-hinotify-0.3.1-9.fc15.0.arm1
- ghc-hslogger-1.1.4-1.fc15.0.arm1
- ghc-html-1.0.1.2-9.fc15.0.arm1
- ghc-HTTP-4000.1.1-5.fc15.0.arm1
- ghc-HUnit-1.2.2.3-4.fc15.0.arm1
- ghc-libmpd-0.5.0-8.fc15.0.arm1
- ghc-MemoTrie-0.4.9-2.fc15.1.0.arm1
- ghc-mmap-0.5.7-5.fc15.0.arm1
- ghc-mtl-2.0.1.0-4.fc15.0.arm1
- ghc-mtl-2.0.1.0-4.fc15.0.arm2
- ghc-mtlparse-0.1.1-5.fc15.0.arm1
- ghc-neither-0.1.0-4.fc15.0.arm1
- ghc-network-2.3.0.2-2.fc15.0.arm1
- ghc-OpenGL-2.2.3.0-7.fc15.0.arm1
- ghc-parallel-3.1.0.1-4.fc15.0.arm1
- ghc-parsec-3.1.1-2.fc15.0.arm1
- ghc-process-leksah-1.0.1.4-5.fc15.0.arm1
- ghc-ranges-0.2.3-2.fc15.1.0.arm1
- ghc-regex-base-0.93.2-5.fc15.0.arm1
- ghc-regex-compat-0.93.1-6.fc15.0.arm1
- ghc-regex-posix-0.94.4-4.fc15.0.arm1
- ghc-regexpr-0.5.3-4.fc15.0.arm1
- ghc-safe-0.3-3.fc15.0.arm1
- ghc-split-0.1.3-4.fc15.0.arm1
- ghc-stm-2.2.0.1-4.fc15.0.arm1
- ghc-syb-0.3-4.fc15.0.arm1
- ghc-tagsoup-0.12-4.fc15.0.arm1
- ghc-tar-0.3.1.0-11.fc15.0.arm1
- ghc-terminfo-0.3.1.3-6.fc15.0.arm1
- ghc-texmath-0.4-6.fc15.0.arm1
- ghc-transformers-0.2.2.0-6.fc15.0.arm1
- ghc-transformers-0.2.2.0-6.fc15.0.arm2
- ghc-uniplate-1.6-5.fc15.0.arm1
- ghc-utf8-string-0.3.6-9.fc15.1.0.arm1
- ghc-X11-1.5.0.0-11.fc15.0.arm1
- ghc-X11-xft-0.3-15.fc15.0.arm1
- ghc-xhtml-3000.2.0.1-9.fc15.0.arm1
- ghc-xml-1.3.7-3.fc15.0.arm1
- ghc-zip-archive-0.1.1.7-2.fc15.0.arm1
- ghc-zlib-0.5.3.1-2.fc15.0.arm1
- ghc-zlib-bindings-0.0.0-4.fc15.0.arm1
gypsy-0.8-2.fc15.0.arm1pbrobinson- java-1.5.0-gcj-1.5.0.0-37.fc15.0.arm1
- kdnssd-avahi-0.1.3-0.11.20080116svn.fc15.0.arm1
- libprelude-1.0.0-8.fc15.0.arm1
- m4-1.4.16-1.fc15.0.arm1
- ocaml-3.12.0-5.fc15.0.arm2
- perl-Coro-5.372-4.fc15.0.arm1
- pl-5.10.2-5.fc15.0.arm1
- python-pyblock-0.49-2.fc15.0.arm1
- pyxf86config-0.3.37-10.fc15.0.arm1
- speedcrunch-0.11-0.2.alpha.fc15.0.arm1
- tzdata-2011h-1.fc15.0.arm1
- xerces-c-3.0.1-21.fc15.0.arm1
- allegro pbrobinson (fixed rawhide/f16 f15 needed)
hwlocpbrobinsonnetcdfpbrobinsonalexpbrobinsonbluetilepbrobinsoncpphspbrobinsoncabal-installpbrobinson