cross-distro October 2011

cross-distro@lists.linaro.org

15 participants
21 discussions

ARM summit at Plumbers 2011

by Steve McIntyre

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

13 years, 5 months

more eglibc pain with armhf / multi-arch

by Steve McIntyre

Just talking to folks in Orlando, and it seems we have another problem... ld.so uses ld.so.cache to look for libraries to load. On a bi-arch system with soft-float and hard-float libs, that could lead to us using the wrong library. Matthias Klose just showed me a broken gcc build where armhh was trying to load libraries from /lib/arm-linux-gnueabi because that's what is listed in the cache. Two solutions present themselves: * move ld.so.cache to a m-a path too; it's currently broken both in having cached data in /etc (!) and in not distingushing properly between systems * add in support for distingushing the ABIs (again!) - currently the 32- and 64-bit x86 systems do this Neither looks like fun... :-( Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

13 years, 10 months

Followup on ARM Minisummit at 2011 LPC

by Jon Masters

[ Please forward this to anyone else who should get a copy - and ask them to signup to cross-distro@linaro because that's where we'll talk ] Folks, At the 2011 Linux Plumbers Conference in Santa Rosa, we held an ARM minisummit to discuss a few cross-distribution issues surrounding the "hard float" ABI for v7, and the ARM device and OS ecosystem in general. This mail is intended to summarize the key actions from that meeting. 1). We discussed some of the different distributions (Debian, ChromeOS, Fedora, MeeGo, Mozilla, Ubuntu, etc.). We all agree on a common notion of what "hard float" means: it's the ARM AAPCS hardware floating point stuff in section 6, with the -d16 register set of the VFPv3 being used. Although there is some possibility to standardize v6, we decided we are interested only in the present and future at this point (and that's v7). Some use Thumb2, some don't, but interworking allows for that (we in Fedora accidentally built a few packages with Thumb2 and will be undoing that without users even noticing). NEON is similarly an optional feature (supported by hwcaps) and not a required part of the core ABI. So it's really just the ABI that we all care about, and we all agree on it. For toolchain folks, this means we all agree on the following: --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux (some of us may target different optimizations, etc. of course but that is down to an application to decide whether it cares only about Cortex+) 2). We agreed on the importance of cross-distro binary compatibility. It seems a number of distributions are excited by Debian's multi-arch approach (as am I), but not all of us will be moving to it any time soon. In the shorter term, if the runtime linker will have a special path, we can work around that with symlinks, but it's a kludge. Our preferred goal (from the meeting) is that everyone use this target: arm-linux-gnueabihf (Red Hat toolchains will include the vendor, but it is dropped by autotools when actually generating the paths and comparisons). I will advocate for Fedora ARM to switch to this target when possible, and in the interim will try to ensure we can establish some symlinks for the ability to run binaries compiled against Debian and Ubuntu on Fedora. I don't know what our timeline will be for this, but it's not something that's really landed everywhere yet. We at least agree on paths now! 3). We agree that it is a good idea to do LSB. Adam Conrad (Canonical) and I agreed to represent community interests in driving this. We do know that we'll be preferring OpenGL ES 2.0 over OpenGL (same namespace within the library means one default choice is required). There will be many other things :) We agree that the main benefit to pursuing LSB is that it promotes the idea of working together and being compatible. It may be that we don't have the same level of compliance on ARM, but some level of conformance to some common standard(s) is a good start! :) 4). We decided that we should have a standing Cross Distro meeting at Linaro Connect events, beginning with the next one in November. We will also facilitate a "show and tell" for apps at Connect, and have an opportunity to demo different distributions. We will add a specific session at the next Connect to continue this discussion. Finally, we agreed we should keep the conversation going. I apologize for being a little tardy in sending this mail, but I want to kickstart further discussion and get this ball rolling again. I'll ping Adam about LSB (and thanks again to Jesse for the deep dive on GL). Meanwhile, David can grab ownership of organizing the Cross Distro meeting at Connect (I would like to assist). Anyone else got actions? Jon.

13 years, 10 months

armhf toolchain patch updates

by Steve McIntyre

Hi folks, 1. eglibc patch for distinguishing ABI at runtime in ld.so I've submitted the patch I was working on, but it's not looking like the eglibc folks are very interested in its current form. There are suggestions on how to proceed with re-engineering it - see the short thread at http://www.eglibc.org/archives/patches/msg01017.html for more info. Being honest, I'm tempted to just leave this work as a proof of concept at this stage. It'll take quite a while to go down the ELF header route, and I fear that we'd have to wait for a lot of changes to flush through before we can get anywhere here. The change to the location of ld.so to move it to the triplet path /lib/arm-linux-gnueabihf/ should be good enough for our purposes anyway. 2. gcc patch to move ld.so to /lib/arm-linux-gnueabihf/ I've been testing and tweaking dannf's gcc patch as proposed at http://lists.linaro.org/pipermail/cross-distro/2011-October/000078.html to get to the attached patch. I've updated it to match the comments that were made here, and it seems to work fine for me: root@panda-smcintyre:/home/steve/src# strings /bin/ls | grep /ld /lib/ld-linux.so.3 root@panda-smcintyre:/home/steve/src# strings ./test | grep /ld /lib/arm-linux-gnueabihf/ld-linux.so.3 Can anyone think of any reasons to not submit it now? Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

13 years, 10 months

Meetings at Linaro Connect next week

by Steve McIntyre

Hi folks, I've added blueprints for the LC/UDS conference in Orlando next week as placeholders for two meetings that I think should be useful: 1. linaro-octo-armhf-status Updates on where we are with the different ports for v7 using the hard-float ABI. There's still some work to do, but it seems that much of it is done at this point. Let's review where we've got to, and what work is left. 2. linaro-summits-cross-distro Continuing cross-distribution meeting series, aimed at sharing ideas and problems that people may have related to ARM porting. There was a good and useful session at Plumbers last month, and we agreed to keep going on these meetings. Let's see how people are getting on and what's new. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

13 years, 10 months