Hi folks,
Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference [1]. I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.
We had some lively discussion about the state of ARM Linux distros at
the Linaro Connect [2] event in Cambridge last week. It rapidly became
clear that some of the topics we discussed deserve a wider audience,
so we're suggesting a meetup at Plumbers for that bigger
discussion. The initial proposed agenda is:
* ARM hard-float
+ What is it and why does it matter?
+ How can distributions keep compatible (i.e. gcc triplet to
describe the port)?
* Adding support for ARM as an architecture to the Linux Standard
Base (LSB)
+ Does it matter?
+ What's needed?
* FHS - multi-arch coming soon, how do we proceed?
* 3D support on ARM platforms
+ Open GL vs. GLES - which is appropriate?
but I'm sure that other people will think of more issues they'd like
to discuss. :-)
If you wish to attend, please reply to the cross-distro list and let
us know to expect you. Make sure you're registered to attend Plumbers
Conf, and get your travel and accommodation organised ASAP.
[1] http://www.linuxplumbersconf.org/2011/
[2] http://connect.linaro.org/
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pardon me for jumping in (and perhaps making some incorrect assumptions)...
I've hit a snag trying to run software that links to ICU
(http://site.icu-project.org/) in Debian Unstable on an armhf box I'm
testing with. I opened a bug report in Debian and posted a question to
the Debian-arm list to see if I could get this issue resolved.
Bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653457
Email thread:
http://www.mail-archive.com/debian-arm@lists.debian.org/msg13111.html
After running some stack traces and reading the patches referenced in
this thread (which are included in the current eglibc 2.13-24 I'm
running) I may have hit an odd problem case.
It turns out that the icu code has a file /usr/lib/libicudata.so.48
which is not actually a normal library. According to the Debian
maintainer for icu, it is actually static data in the form of a library
used as a speed hack for loading times. When I run any code that links
that library, I get an uncommented exit during library loading with a
code of '1'.
Could I possibly be hitting the "#ifdef __ARM_PCS_VFP" case and exiting?
How can I fix this case? I'll be happy to test any patches.
Tony
- --
Anthony L. Awtrey
http://awtrey.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO+29SAAoJEAPVzrg8OofbswgH/R/Uu0geaQc5wACR0PUTz8ey
O5U/hPesVCqAfSLY7AduUVuxNEwtiUwuA9D/dhmDu63HwPAniF2s/OxTdkKICwKz
NaFkw9xr5/UnO0aHCDnNh2Dg84U0ihfRX9aS+2cQwFyaAKZzIORkhOD3f9U937G2
zqGSWiX+gJXmj/15ylpd4fXqfKhFyGE/pEnU/uRbaSnRfa731plOI1AlDNsWRi0I
ve0YGVSluqBiY9eqLz1I/iEjb7QFuOqtGG/GeWsDk6bIdc/PYLToGHZLiFqC7/Lh
qRnZ0/lYPour+tbz9uZh3Y3GCMG4YkcwF/HKSbtLMfa7Ur7iFVf+0OA36qdkaxs=
=XCXi
-----END PGP SIGNATURE-----
On arm* sys/ucontext.h heavilly polloutes the global
namespace firstly by including sys/user.h (which defines
among other things a type called "struct user" and secondly
by defining symbols and #defines named R? to represent
the processor registers.
That issue in itself is nothing new but fairly recently*
signal.h started including sys/ucontext.h by default
causing programs that (quite reasonable IMO) used those
names for their own symbols to fail to build on arm. This
has been especially noticable recently because debian is
trying to build the new "armhf" port.
After discussions on debian-arm/debian-glibc/linaro-dev
(I do not know which responders came from which list)
I was given the following advice on the "struct user"
issue by Ulrich Weigand.
>Now, glibc also provides a file <sys/ucontext.h> that defines
>layouts of register sets for use with signal handlers as well
>as the makecontext/setcontext/getcontext family of routines.
>
>Usually, those layouts tend to be in fact identical to the
>layouts described in <sys/user.h> / <sys/procfs.h>. Apparently,
>whoever implemented the ARM version of <sys/ucontext.h> was
>trying to avoid some seemingly unnecessary code duplication
>by making <sys/ucontext.h> *include* <sys/procfs.h> and using
>the information from there directly. This is not done on other
>platforms, for precisely the reason that the <sys/procfs.h>
>and <sys/user.h> headers do pollute the name space ...
>
>So I think the right thing to do in the short term would be to
>stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the
>register set information there directly, even if that means some
>duplication of code. (Again, since this is never-changing ABI,
>duplication isn't actually all that bad. Also, all the other
>platforms do it that way too, so why should ARM be different ...)
On the issue of the R? definitions I proposed renaming them
to REG_R?. The use of a REG_ prefix is consistent with
x86, x64 and sparc (I couldn't find any comparable definitions
at all on other architectures I looked at) I asked what the
impact of this change would be on the aforementioned mailing
lists and got the following reply from Konstantinos Margaritis
>at worst the packages that had to be workaround on arm* for this, can
>have the workaround removed.
The attached patch implements these changes.
My tests did not show any new failures in the libc testsuite (though
I did get failures that debian considers "unexpected" regardless
of whether this patch is applied or not)
The patch was accepted upstream by Joseph Myers <joseph(a)codesourcery.com>
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff;h=c1e30fd8bffd53a…
The patch was also accepted in debian sid by Aurelien Jarno
<aurel32(a)debian.org>
http://packages.qa.debian.org/e/eglibc/news/20111225T171844Z.html
I have been advised by hector oron to send this to the cross-distro list
in-case other distros are interested in applying this fix before it filters
down naturally from upstream.
* I have not investigated exactly when this change occoured
but it was somewhere between the version in ubuntu lucid
and the version in ubuntu maverick.
