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
Hey folks,
Continuing on from the discussions at LC last week, here are my two
patches. They work OK for me in testing on armhf and armel builds
here, so I hope they are helpful for other people.
Background: in bi-arch and multi-arch configuration, soft-float and
hard-float libraries do not play well together at all:
* ldconfig (currently) does not distinguish between the two ABIs when
scanning libraries and putting their details in ld.so.cache, so if
you have libs of both ABIs installed on your system then there is
no guarantee that the right one will be used when needed.
* ld.so (currently) cannot verify at run-time whether a given lib
uses the hard-float or soft-float ABI, which can lead to similar
problems.
I previously had just a patch against ld.so for this, causing it to
fail to load a library when the wrong ABI was detected. However, more
testing has shown that this is not a sufficient solution. ld.so trusts
the contents of the cache, so I've had to add logic into ldconfig
itself and add extra information in the cache to describe the ABI of a
library. There's already similar code in there to recognise 32-bit
libs on a 64-bit system, so I've extended things in what I hope is a
clean way. Unfortunately, there are also paths through ld.so that
*don't* use the cache anyway so we still need the checks in there as
well. If the wrong lib is loaded by mistake, return ENOENT so that a
fallback is attempted.
For now, there's a fair amount of duplication in the code in each
patch. I'd be happier to see it cleaned up and shared better, but my
initial efforts in that direction have been thwarted by the internals
of eglibc - the (very minimal) infrastructure available in ld.so is
very different to that in ldconfig (an entirely normal and boring C
application). If anybody fancies trying that cleanup, please feel
free... :-)
As the list drops attachments, here are links to the two patches:
http://people.linaro.org/~stevemcintyre/armhf/unsubmitted-ldconfig-cache-ab…http://people.linaro.org/~stevemcintyre/armhf/unsubmitted-ldso-abi-check.di…
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hi guys,
We are currently slightly stuck in getting GNU Java to work properly on
our ARM (hf) builds. Something breaks in the unrolling of exceptions.
IIUC Fedora already managed to get Java running and I don't want to
waste too much time in duplicated efforts.
We found some patches that looked like they might be related here:
http://djdelorie.fedorapeople.org/armv7-srpms.html (gcc pkg)
but couldn't find the source rpms to the respective info. Are these
related / required? Does anyone have some insight in what exactly you
have been fixing?
Btw, this is what we're seeing:
---
+ gcj -C /home/abuild/rpmbuild/SOURCES/keystore.java -d .
qemu: uncaught target signal 6 (Aborted) - core dumped
gcj: internal compiler error: Aborted (program ecj1)
---
Alex
