>Architecture-dependent bits of PERL, as far as I can see. Except
>hardly dependent between armv*.
If this is stuff in, say, /usr/lib/perl5/armv4l then the only thing that
matters is that the granularity is high enough that no two incompatible
versions clash. It's not a big deal if you end up with /usr/lib/perl5/armv4l
and /usr/lib/perl5/armv5l being actually interchangeable -- what we need to
avoid is for, say, there being an ambiguity between a big-endian version and
a little-endian version.
>more to contend with. My question is this: what is there about the
>particular revision 4 of the architecture that makes it suitable as a
>label for all the released RPMs -- why not version 3, or undoubtedly
Simply the fact that v4 is the current most common architecture. If you are
using only ARMv3 instructions then you can feel free to use `armv3' or
whatever if you like. I don't know RPM well enough to say whether you can
convince it that armv3 RPMs are OK to install on a v4 machine.
>I would, I think, favour removing the current what-I-see-as-a-kludge
>that inhibits LDRH/STRH on armv4 (unless specifically specified), and
It's not specifically inhibited, just that gcc has no code to link the code
generation options to the details of the target name. So rather than removing
a kludge you would be implementing a feature. But I don't really feel this is
worth while. Distribution makers can decide what platforms they want to
support and configure GCC appropriately. For most users it's (in my view)
best to default to conservative settings.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
