Busybox on ARM, possible GCC issues
by Gordan Bobic
Hi,
I've been trying to get busybox to build on Fedora ARM and I've vixed a
few issues with the RPM, but one still remains:
/builddir/build/BUILD/busybox-1.15.1/scripts/trylink
"busybox_unstripped" "gcc" " -Wall -Wshadow -Wwrite-strings -Wundef
-Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function
-Wunused-value -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen
-finline-limit=0 -fomit-frame-pointer -ffunction-sections
-fdata-sections -fno-guess-branch-probability -funsigned-char
-static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1
-falign-loops=1 -Os -fno-asynchronous-unwind-tables
-fno-stack-protector -static -nostartfiles
-LuClibc-0.9.30.1/installed/lib uClibc-0.9.30.1/installed/lib/crt1.o
uClibc-0.9.30.1/installed/lib/crti.o
uClibc-0.9.30.1/installed/lib/crtn.o" " " " applets/built-in.o" "
archival/lib.a archival/libunarchive/lib.a console-tools/lib.a
coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a
e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a
libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a
modutils/lib.a networking/lib.a networking/libiproute/lib.a
networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a
selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a
util-linux/volume_id/lib.a archival/built-in.o
archival/libunarchive/built-in.o console-tools/built-in.o
coreutils/built-in.o coreutils/libcoreutils/built-in.o
debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o
findutils/built-in.o init/built-in.o libbb/built-in.o
libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o
miscutils/built-in.o modutils/built-in.o networking/built-in.o
networking/libiproute/built-in.o networking/udhcp/built-in.o
printutils/built-in.o procps/built-in.o runit/built-in.o
selinux/built-in.o shell/built-in.o sysklogd/built-in.o
util-linux/built-in.o util-linux/volume_id/built-in.o" " m crypt"
Trying libraries: crypt m
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused
-Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes
-Wmissing-declarations -Wdeclaration-after-statement
-Wold-style-definition -fno-builtin-strlen -finline-limit=0
-fomit-frame-pointer -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -static-libgcc
-falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os
-static -nostartfiles -LuClibc-0.9.30.1/installed/lib
uClibc-0.9.30.1/installed/lib/crt1.o
uClibc-0.9.30.1/installed/lib/crti.o
uClibc-0.9.30.1/installed/lib/crtn.o -o busybox_unstripped
-Wl,--sort-common -Wl,--sort-section,alignment -Wl,--start-group
applets/built-in.o archival/lib.a archival/libunarchive/lib.a
console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a
debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a
init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a
miscutils/lib.a modutils/lib.a networking/lib.a
networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a
procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a
util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o
archival/libunarchive/built-in.o console-tools/built-in.o
coreutils/built-in.o coreutils/libcoreutils/built-in.o
debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o
findutils/built-in.o init/built-in.o libbb/built-in.o
libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o
miscutils/built-in.o modutils/built-in.o networking/built-in.o
networking/libiproute/built-in.o networking/udhcp/built-in.o
printutils/built-in.o procps/built-in.o runit/built-in.o
selinux/built-in.o shell/built-in.o sysklogd/built-in.o
util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group
-Wl,--start-group -lcrypt -lm -Wl,--end-group
==========
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_eh.a(unwind-arm.o):
In function `__gnu_Unwind_Backtrace':
(.text+0x8b0): undefined reference to `__stack_chk_fail'
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_eh.a(unwind-arm.o):
In function `__gnu_Unwind_Backtrace':
(.text+0x8b8): undefined reference to `__stack_chk_guard'
collect2: ld returned 1 exit status
Poking around with the command that fails, it would appear that it is
-lm that causes the problem, and that appears to be in libgcc.
I tried adding -fno-stack-protector and -fno-asynchronous-unwind-tables
to this operation, but the problem doesn't go away. I have a sneaky
suspicion that I may (also) need to add this to the uClibc CFLAGS, but
that seems to cause build failures early on.
Any suggestions for a workaround?
Gordan
12 years, 5 months
Outage: Fedora ARM Build Farm 2011-10-25 14:00 UTC
by Chris Tyler
There will be an outage starting at 2011-10-25 14:00 UTC, which will
last approximately 4 hours. (Services will be restored incrementally,
with the x86_64 hosts coming up first, followed by the ARM builders).
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2011-10-25 14:00 UTC'
Reason for outage:
Physical maintenance/rearrangement/rewiring to improve cooling and
manageability.
Affected Services:
ARM Koji - arm.koji.fedoraproject.org
Moji - moji.proximity.on.ca
ARM builders:
cdot-guru-*-*
cdot-smarttop-*-*
cdot-panda-*-*
cdot-beagle*-*-*
cdot-openrd-*-*
cdot-sheeva-*-*
Related servers:
hongkong.proximity.on.ca = arm.koji.fedoraproject.org
australia.proximity.on.ca = moji.proximity.on.ca
scotland.proximity.on.ca
ireland.proximity.on.ca
Unaffected Services:
Non-ARM Secondary Architecture services
Non-Seneca ARM servers
Contact Information:
ctyler(a)fedoraproject.org - irc://ctyler@irc.freenode.net/fedora-arm
jordran.cwang(a)senecac.on.ca - irc://jacwang@irc.freenode.net/fedora-arm
Please join #fedora-arm in irc.freenode.net
12 years, 5 months
Fedora 16
by Dennis Gilmore
hey everyone,
So ive done some thinking, and talked with some of the stakeholders.
Ive come to the conclusion that we should skip f16 and shoot straight
for rawhide. two reasons for this. one to become a primary arch at some
point we need to be caught up and doing releases at the same time. my
long term goal is for arm to become a primary arch and the second
reason why i think that we should skip f16 is that its easier to get
help from maintainers when doing things in rawhide. I wanted to get a
quick note out there to get discussion going.
I suspect there are some pieces of f16 we will need to build to get
things right. and if we get caught up quickly and can follow the
branching from rawhide to f17 there is no reason we cant back track
around and do f16 i just feel that once we get f15 done we should get
moving towards parity. and showing that arm works and can keep up and
follow along.
Dennis
12 years, 5 months
ghc bootstrapped for armv5tel (and armv7hl earlier)
by Henrik Nordström
Bootstrapping of GHC is now completed for both armv7hl and armv5tel.
armv7hl packages is in stage4 since a month back.
mock built amv5tel packages can be found at
http://repos.fedorapeople.org/repos/hno/armv5tel/fedora-15/
ghc
hscolour
ghc-rpm-macros
redhat-rpm-config
built from current Fedora-15 mainline releases, where ghc, hscolour &
ghc-rpm-macros is all in updates-testing and redhat-rpm-macros is only
in koji (trivial change adding armv7hl & armv5tel to ghc supported arch
list).
In the armv7hl stage4 repository there is also a large number of
slightly modified ghc related packages adding armv7hl as a supported
arch. It's not yet decided how many of these will be updated for F15 to
use the right arch specifications %{ghc_arches}. None of these needs to
be dealt with before moving to koji and will build fine as F15 updates
later on, or when we move to F16 where this change was already done.
Regards
Henrik
12 years, 5 months
Re: [fedora-arm] request/suggestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation
by Joop Boonen
On Sat, October 22, 2011 3:52 pm, Konstantinos Margaritis wrote:
> On 22 October 2011 16:17, Joop Boonen <joop.boonen(a)boonen.org> wrote:
>> Hi all,
>>
>> Most of the (ARM) distros are currently working on or in the transition
>> to
>> hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
>> hardfp drivers yet.
>>
>> To be able to have a ARM hardfp compiled X Window desktop
>> system/notebook
>> with 3D support we need hardfp compiled drivers.
>>
>> I was thinking it might be more efficient is all Linux distro's work
>> together to get these drivers as it's equally important for all distro
>> that wants to move to a hardfp distro.
>>
>> What do you all think, who wants to work together to get full hardfp
>> support for as most as possible ARM SOC GPUs?
>>
>> It would be great if we can in the end even have OSS drivers.
>
> Hi,
>
> Nvidia was the first to release hardfp drivers for tegra2 gpus for
> armhf, and we also have working drivers for hardfloat for the
> Freescale i.MX51 and i.MX53 gpus, which we use on our current and
> upcoming products (Genesi Smarttop/Smartbooks). It took a lot of time
> and effort on our side to push for that, and obviously not for
> technical reasons -it was just a 5 minute recompile of a binary static
> library.
I can imagine. I understood that the MX51 has a AMD Z430 GPU. Which has
been renamed to Adreno 200 (AMD Z430), as Qualcomm bought the handheld
graphics unit from AMD.
http://en.wikipedia.org/wiki/Imageon
So you probably have to go through FreeScale that might need approval from
Qualcomm to build a hardfp driver.
I understood that in the ARM SOC world the SOC producer is responsible for
the video driver, which is very different from the PC world where the
designer is delivers the driver (NVidia/AMD/Intel).
> But in the end it was worth it. We're getting 15-20% increase
> in performance on average -sometimes more- in our GLES benchmarks, and
> we're working to squeeze more performance out of that -I'm currently
> working on neon-optimizations in the GLES1 backend, which may not be
> current, but it's still used by some important and very much needed
> applications (i.e. quake3 :).
>
> So, the list is short right now, but that is the least of our
> problems. The real problem is getting all of the kernel gpu drivers
> into a single (mainline?Linaro?) kernel tree. The vendors are very
> resistant in releasing specs or source code, and the kernel guys are
> equally -if not more- resistant in accepting half-open/half-closed
> drivers into the kernel tree.
I think this is de to GPL, that why they only allow open source modules
for the kernel. That's also why the proprietary kernel modules for NVidia
and AMD are not in the standard kernel.
> It's going to be a long road, but I
> think that eventually we're getting there, unless of course a miracle
> happens and all vendors simultaneously opensource their drivers :)
I hope it will happen soon. It feels the time when NVidia and ATI didn't
build any (3D) drivers for Linux. This slows down Linux development a lot
and it'll limit that hardware you'll be able to use Linux on.
>
> Regards
>
> Konstantinos
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
Regards,
Joop.
12 years, 5 months
request/sugestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation
by Joop Boonen
Hi all,
Most of the (ARM) distros are currently working on or in the transition to
hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
hardfp drivers yet.
To be able to have a ARM hardfp compiled X Window desktop system/notebook
with 3D support we need hardfp compiled drivers.
I was thinking it might be more efficient is all Linux distro's work
together to get these drivers as it's equally important for all distro
that wants to move to a hardfp distro.
What do you all think, who wants to work together to get full hardfp
support for as most as possible ARM SOC GPUs?
It would be great if we can in the end even have OSS drivers. And to have
a good relationship with the GPU designers (for ARM SOCs) and hardware
producers.
If you know other distro's that are working on an ARM port or people that
might want to help, an you please forward the email to them?
Regards,
Joop.
12 years, 5 months