cross-distro December 2011

cross-distro@lists.linaro.org

4 participants
5 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 … [View More]

13 years

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/… [View More]

13 years, 3 months

Koji - RPM naming

by webwillow＠thewebwillow.com

13 years, 3 months

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 … [View More]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. [View Less]

13 years, 3 months

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

13 years, 4 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro December 2011