cross-distro

cross-distro@lists.linaro.org

147 discussions

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

by Michael Hope

On 4 April 2012 04:17, Andrew Haley <aph(a)redhat.com> wrote: > On 04/03/2012 05:09 PM, Richard Earnshaw wrote: >> On 03/04/12 12:01, Jakub Jelinek wrote: >>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: >>>> If, so then there's only one way to sort out this mess. >>>> >>>> /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader >>>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader >>> >>> The above scheme is a Debianism which no other distro is using. >>> >>> Jakub >>> >> >> Not really, it's just a naming convention for where the config-specific >> dynamic loader lives. It doesn't affect where the remaining shared >> libraries live. >> >> The subdirectories could be called fred and jim and it would still work. >> The only thing required is that this part of the naming scheme be >> agreed amongst the distros. >> >> This looks to me like it's turning into a bike-shed painting excerise >> between the distros out there. That's really sad. > > I don't think we ever even had the discussion: Debian invented their > Debian-internal scheme for managing multiple ABIs. They have in the past > used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros. -- Michael [1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html

13 years, 10 months

Re: Wanted: superstar hacker to complete Mono port to armhf

by Hector Oron

Hello Jo, I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI. 2012/2/2 Jo Shields <directhex(a)apebox.org>: > Right now, Mono is available in Debian armhf. This is a hack - what > we're actually doing is building Mono as an armhf binary, but built to > emit soft VFP instructions and using calling conventions and ABI for > armel. This hack works well enough for pure cross-platform code (like > the C# compiler) to run, but dies in a heap for anything complex. > > This situation is a bit on the crappy side of crap. > > In order for Mono on armhf not to be a waste of time, a "true" port > needs to be completed. If I were to make a not-remotely-educated guess, > I'd say it needs about 550 lines of changes, primarily the addition of > code to emit the correct instructions feeling the correct registers in > mono/mini/mini-arm.c plus a couple of tweaks to related headers. > > Upstream have also indicated that they're happy to provide guidance and > pointers on how to implement this port, although they're unable to > provide the requisite code themselves. > > Sadly, unless someone in the community is able to step forward and > contribute here, it's only a matter of time before the armhf packages > are rightfully marked RC-buggy, and 100+ packages need to be axed from > armhf. This would make me sad. -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.

13 years, 10 months

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, 10 months

Forthcoming meetings

by Steve McIntyre

Hi folks, In the coming few weeks, I've got space/time organised for some more face-to-face meetings in case they're useful: * ARM BoF at FOSDEM (currently scheduled for Sunday afternoon 5th Feb in one of the distro Devrooms) * Session(s) at Linaro Connect in San Francisco the following week I'm expecting to (at least) discuss ARM progress in various distros (including the new HF ABI) and build/port issues. If you have anything you'd like to discuss at one or both of these events, please speak up and/or come along! Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years

SuperLinux Build Farm.

by webwillow＠thewebwillow.com

14 years, 1 month

Re: multi-arch soft/hard-float patches for ldconfig and ld.so

by Anthony L. Awtrey

-----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-----

14 years, 1 month

Koji - RPM naming

by webwillow＠thewebwillow.com

14 years, 1 month

patch to reduce sys/ucontext.h namespace polloution on armel

by peter green

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.

14 years, 1 month

[Fwd: [lsb-discuss] LSB and FHS restoration plan]

by Jon Masters

Folks, Let's make a New Year's Resolution that we're going to tackle LSB on ARM systems and get it done. Jon.

14 years, 2 months

Koji Hints

by webwillow＠thewebwillow.com

14 years, 2 months

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro