Re: arm eabi port, patches
On Wed, Jan 10, 2007 at 07:36:29PM +0200, Riku Voipio wrote:
> > I can't share the debs yet (internal and customer use only for now),
> Is publishing estimated how soon?
I hope soon, but I can't say yet, and I'm not the one deciding this.
In my opinion, it's only fair that the people who paid for the work
get the opportunity to implement and use it for some time before
other people do.
(If the official EABI port had been available sooner, we wouldn't be
in this situation. :-/)
> IE. Should someone start writing a more official announcement that
> clarifies to the non-arm people why the new port is usefull?
I think this would be a good thing in any case. If people are aware
of the EABI, it is hopefully easier for a non-Debian Developer like me
to get armel patches merged.
[ One thing I would like to ask is if people submit/apply patches that
add 'armel' to the debian/control Architecture: line, to add 'armeb'
to there as well. I submitted patches to add 'armeb' to a bunch of
packages in the sarge days, but a number of those patches never got
applied, and a lot of new packages have only 'arm' and not 'armeb'. ]
> > I asked Joey Hess, and he felt that there are probably more packages
> > that depend on linux-gnu than on having gnueabi, which makes sense.
> > The only packages that really need to know about gnueabi are binutils,
> > gcc and glibc, the rest should just be checking defined(__ARM_EABI__).
> > Opinions?
> I agree, we have a pile of patches (mostly against sarge versions..).
> Most of them do not really make sense, linux-gnueabi is effectively
OK, so -gnu it is, then? Guillem, do you agree?
This is what I have now:
Does it still need an ABI tag, or can we just special-case 'armel' in
the rules files for binutils, gcc and glibc?
> IIRC In non-toolchain apps, the only eabi patch where you acually
> needed to be different was perl, where perl optimizes for armv3 on
> oldabi arm.
Right. There's also a bunch of packages that assume that they need
__attribute__((packed)) on all ARM systems, which is no longer always
true with EABI, and there's also a bunch of packages that still assume
FPA word order even if defined(__VFP_FP__). These will need patching
for EABI in any case. I have patches for a number of them.