Greetings.
For those that have seen or heard about some of the work going
on with Fedora and Linaro [0], there are times when it makes
sense to do work with the cross-compilers for ARMv7/ARMv8 that
Linaro provides.
Unfortunately, these have not until now been packaged for Fedora.
I have created a yum repo [1] that currently has the cross-tools
available for Fedora 18 on x86_64. These allow you to cross-build
on Fedora, and target Fedora 18 on ARM [2].
Add the following to /etc/yum.repos.d as a new file:
[linaro-tools]
name=linaro-tools
baseurl=http://repos.fedorapeople.org/repos/ahs3/linaro-tools/fedora-18/x86ā¦http://repos.fedorapeople.org/repos/ahs3/linaro-tools/fedora-18/noarch/http://repos.fedorapeople.org/repos/ahs3/linaro-tools/fedora-18/SRPMS/
enabled=1
gpgcheck=1
Then, you should be able to install the cross-tools for the ARM
architecture you want with:
# yum install fedora-linaro-gcc-arm-linux-gnu
or
# yum install fedora-linaro-gcc-aarch64-linux-gnu
Hope these help...feel free to let me know if there's any issues
with them...they work for me but that is never enough testing :).
Notes:
[0] https://wiki.linaro.org/LEG -- Linaro Enterprise Group
[1] The goal is to ultimately get these into Fedora officially,
but I thought they might be useful before that process has
been completed.
[2] Tools for cross-building on Fedora with the Linaro environment
as a target are still a work in progress.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
> Fellow arm members I am just sending out a quick update to let everyone know that the rpfr-f18-rc1 v5 release is available. As always special thanks to everyone who contributed to help put this together.
>
> v5 Image:
> http://scotland.proximity.on.ca/raspberrypi/raspberrypi-fedora-remix/18/imaā¦
Was wondering if any effort is planned to reduce the file size of the
image (e.g. exclude documentation and large icon sets), and upload the
image to a faster mirror.
Download speed leaves to be desired:
==
$ wget
http://scotland.proximity.on.ca/raspberrypi/raspberrypi-fedora-remix/18/imaā¦
--2013-02-12 18:04:58--
http://scotland.proximity.on.ca/raspberrypi/raspberrypi-fedora-remix/18/imaā¦
Resolving scotland.proximity.on.ca (scotland.proximity.on.ca)...
142.204.133.151
Connecting to scotland.proximity.on.ca
(scotland.proximity.on.ca)|142.204.133.151|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1192865310 (1.1G) [application/zip]
Saving to: `rpfr-f18-rc1.zip'
0% [ ] 1,325,391 50.2K/s eta 7h 36m
==
(have 100 mbit fiber at home, in case you suspect my own Internet
connection of being the problem)
--
Yours sincerely,
Floris Bos
Kernel-3.7.5-201.fc18 is currently in updates, but appears it may have an issue booting on
the Pandaboard ES. Can anyone with an ES confirm this?
fpaste of the boot - http://st3fan.pastebin.mozilla.org/2131908
Thanks,
Paul
I've heads down lately building RPMs in stage3 and haven't posted any
status in a while. I updated the wiki this morning with notes on the
packages built so far:
http://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage3Notes
I think we now have everything in the rootfs which is needed to run mock
itself. What we lack are packages to populate a repo which mock can use
for it's chroot. We have built a lot of the necessary packages in stage3
but there is a problem with using those in the mock chroot. That problem
is due to glibc.
>From the start in stage1, we have been using glibc 2.16 patched with
aarch64 support. Everything to date has been built against this glibc.
In the meantime, glibc 2.17 has been released upstream with aarch64 in
place. So at this point, it really makes sense to switch to 2.17 but
therein lies the problem. The upstream release has no compatibility
with 2.16 because 2.17 is the first release with aarch64 support. So
if one simply replaces the glibc binaries in the rootfs, nothing runs
because all of the other ELF binaries want to link against libraries
with glibc-2.16 version support.
We could get around this by just starting over from stage1 using the
new glibc. This wouldn't take as long as the first time because we have
already dealt with patches for failing packages. Even so, I think it
would take two or three weeks to get through all the builds since they
must be done serially in dependency order for the most part.
Not wanting to wait that long for a full rebuild, I looked at how to
work around the problem. I ended up with a small app which searches
through the existing ELF files and patches them so that they think
they were linked against 2.17 instead of 2.16. After a few false starts
I got it sorted out where the rootfs with patched binaries would boot
and I could replace the existing glibc libs with ones from a crossbuilt
2.17. Newly built binaries are now linked against 2.17 and we can avoid
the full rebuild. Of course, the binary RPMs we have built to date still
have binaries in them which require the 2.16 libraries, so they would
be unusable with glibc-2.17 in a mock chroot. I still haven't pushed the
patched ELF binaries to the git tree, so now would be a good time for
others to object to that ugly hackery or propose some other way of
working around the problem.
In the meantime, I am working on getting glibc-2.17 to build natively
from rpm. There are some issues there which will probably need some
patches to glibc itself and to the spec file. This is taking a lot of
time because of the build times on the sim. It makes restarting the
build painful, so I'm working through %install stage manually by
patching the specfile and using --short-circuit to avoid the %build
stage. I want to have something to use in a mock chroot ASAP and
leave proper patches for later once I have the full picture of what
is broken.
--Mark
Good Morning all,
Join us today at 11am (EST), for a Virtual Fedora Activity Day (VFAD) to
refresh the documentation on the Fedora ARM wiki - removing any
references to older releases, updating any outdated links and adding
additional content to help people get involved with Fedora ARM.
Some of the content we would like to add was discussed at FUDCon Lawrence
last month, and Jared put together a document outlining the topics:
http://piratepad.net/L1jH2TLCBO
If your unable to join us today, but would like to contribute please
respond to the list with your ideas or write up and we can ensure its
added.
Paul