Riku Voipio wrote:
On Tue, Apr 04, 2006 at 12:09:11PM +0200, Pjotr Kourzanov wrote:
Thats unreleated to architecture strings. It's worth remembering
that compliler flags rarely turn O(n^2) solutions into O(1) solutions. The
linear max 5% increase will not solve the real big performance
prob
On Tue, Apr 04, 2006 at 12:09:11PM +0200, Pjotr Kourzanov wrote:
> >Thats unreleated to architecture strings. It's worth remembering
> >that compliler flags rarely turn O(n^2) solutions into O(1) solutions. The
> >linear max 5% increase will not solve the real big performance
> >problems.
> *smal
On Tue, 04 Apr 2006 13:30:24 +0200, Pjotr Kourzanov wrote:
> Daniel Gimpelevich wrote:
>
>> [quoted text muted]
> What is the kernel in your view, btw? AFAICT it is still software;-)
It's software that's already compatible with -mhard-float and
-msoft-float. Wouldn't the kernel need to be recomp
On Tue, 04 Apr 2006 13:20:00 +0200, Pjotr Kourzanov wrote:
> Peter 'p2' De Schrijver wrote:
>
>> [quoted text muted]
> I think we can restrict ourselves to most useful, popular
> ones (i.e., the ones that can/will be actively maintained):
>
> arm-> arm4, le, glibc, oabi-hard-
Daniel Gimpelevich wrote:
On Tue, 04 Apr 2006 12:43:29 +0300, Riku Voipio wrote:
On Mon, Apr 03, 2006 at 10:28:29AM -0700, Daniel Gimpelevich wrote:
That is precisely why I am suggesting here that -mhard-float be dumped
altogether in favor of -msoft-float, but have the soft-float
impl
Peter 'p2' De Schrijver wrote:
Hi,
Hi,
Agreed with guillem that we'll decide this at the Extremadura
meeting next week, else we'll end up like the amd64 port with
flaming for the name choice in tech-ctte..
should be clear why current dpkg-architecture limits our choices.
Riku Voipio wrote:
Hi,
Agreed with guillem that we'll decide this at the Extremadura
meeting next week, else we'll end up like the amd64 port with
flaming for the name choice in tech-ctte..
Yes, please, make this as simple as arm-eabi.
should be clear why current dpkg-architecture l
Hi,
> Hi,
>
> Agreed with guillem that we'll decide this at the Extremadura
> meeting next week, else we'll end up like the amd64 port with
> flaming for the name choice in tech-ctte..
>
> > >should be clear why current dpkg-architecture limits our choices.
>
> (emphasize on current)
>
> >
On Tue, 04 Apr 2006 12:43:29 +0300, Riku Voipio wrote:
> On Mon, Apr 03, 2006 at 10:28:29AM -0700, Daniel Gimpelevich wrote:
>> That is precisely why I am suggesting here that -mhard-float be dumped
>> altogether in favor of -msoft-float, but have the soft-float
>> implementation code be a shared
Hi,
Agreed with guillem that we'll decide this at the Extremadura
meeting next week, else we'll end up like the amd64 port with
flaming for the name choice in tech-ctte..
> >should be clear why current dpkg-architecture limits our choices.
(emphasize on current)
>
> Pardon me, but to me it l
On Mon, Apr 03, 2006 at 10:28:29AM -0700, Daniel Gimpelevich wrote:
> That is precisely why I am suggesting here that -mhard-float be dumped
> altogether in favor of -msoft-float, but have the soft-float
> implementation code be a shared object that can be replaced as needed.
..which would break b
On Mon, 03 Apr 2006 12:25:17 +0200, peter.kourzanov wrote:
>> This may very well be a nauseatingly unworkable suggestion, but for the
>> old ABI, it seems to me the most optimal compromise can be achieved if
>> everything used a shared-object soft-float library that could be swapped
>> out and rep
On Sun, Apr 02, 2006 at 10:57:23PM -0700, Daniel Gimpelevich wrote:
> On Thu, 30 Mar 2006 15:07:16 +0100, Martin Guy wrote:
>
> >> Isn't FPU something more related to the CPU rather than LIBC or ABI?
> >
> > Yes and no. There are many interrelated questions.
> >
> > There is the physical FPU t
On Thu, 30 Mar 2006 15:07:16 +0100, Martin Guy wrote:
>> Isn't FPU something more related to the CPU rather than LIBC or ABI?
>
> Yes and no. There are many interrelated questions.
>
> There is the physical FPU that a particular user has in their
> computer, which is currently one of:
> none,
On Thu, Mar 30, 2006 at 03:07:16PM +0100, Martin Guy wrote:
> > Isn't FPU something more related to the CPU rather than LIBC or ABI?
>
> Yes and no. There are many interrelated questions.
Sure, choosing a FP method (softfloat, FPA, VFP etc.) relates
to the binary instance of a certain C libra
"Martin Guy" <[EMAIL PROTECTED]> wrote:
> So part of the point of moving to ARM EABI is to move to an ABI that
> allows us to distribute binary packages that will still run on
> everything (well, everything down to the armv4 family anyway)
^
As I under
> Isn't FPU something more related to the CPU rather than LIBC or ABI?
Yes and no. There are many interrelated questions.
There is the physical FPU that a particular user has in their
computer, which is currently one of:
none, FPA, VFP, MaverickCrunch or iWMMXt (not really an FPU they tell me)
On Thu, Mar 30, 2006 at 11:59:54AM +0100, Martin Guy wrote:
> > "arm", "i386", "m68k" are shorthands. Please have a look at
> > dpkg-architecture sources:
> >
> > if ($os eq "linux") {
> > return $cpu;
> > } else {
> > return "$os-$cpu";
> > }
> >
> > Next, have a look a
> > variants (there is a list at popcorn.debian.org) and to future-proof
> ^
> There's movies there, too? ;-)
Oh, bum! I mean popcon.debian.org
M
On Thu, Mar 30, 2006 at 10:14:25AM +0100, Martin Guy wrote:
> Rather than choose a soapbox to stand on, I'll suggest a few criteria
> for it to fit in with the schemes for existing Debian architecture
> variants (there is a list at popcorn.debian.org) and to future-proof
> "arm", "i386", "m68k" are shorthands. Please have a look at
> dpkg-architecture sources:
>
> if ($os eq "linux") {
> return $cpu;
> } else {
> return "$os-$cpu";
> }
>
> Next, have a look at ostable and cputable files. After that I think it
> should be clear why curren
Riku Voipio wrote:
On Thu, Mar 30, 2006 at 10:31:58AM +0100, Martin Guy wrote:
dpkg-architecture in dpkg 1.13 returns "os-cpu", where os and arch are
grabbed from ostable and cputable.
Er... are we talking about different meanings of the word "architecture" here?
s/os and arch
Riku Voipio wrote:
Hey everyone,
please keep some perspective. It's just a name. It does not really
need this much discussion. We just need to decide some name and
stick for it. If we start discussing new naming policies now, there
is going to be no end to the discussion, as it MOSTLY a matter
On Thu, Mar 30, 2006 at 10:31:58AM +0100, Martin Guy wrote:
> > dpkg-architecture in dpkg 1.13 returns "os-cpu", where os and arch are
> > grabbed from ostable and cputable.
> Er... are we talking about different meanings of the word "architecture" here?
s/os and arch/os and cpu/
> This discussio
Hey everyone,
please keep some perspective. It's just a name. It does not really
need this much discussion. We just need to decide some name and
stick for it. If we start discussing new naming policies now, there
is going to be no end to the discussion, as it MOSTLY a matter of
taste and everyone
On Thu, Mar 30, 2006 at 03:40:40AM +0300, Guillem Jover wrote:
> | armel (confusing: "armeb" is already taken for bigendian old-ABI)
>
> Is there any plan for armeb to switch to EABI before getting into the
> archive? If there is this would not be as confusing. Also it would be
> nice if the name
> dpkg-architecture in dpkg 1.13 returns "os-cpu", where os and arch are
> grabbed from ostable and cputable.
Er... are we talking about different meanings of the word "architecture" here?
This discussion is about the new equivalent to "arm", "i386", "m68k"
and so on, as used in the file names for
Riku Voipio wrote:
On Thu, Mar 30, 2006 at 03:40:40AM +0300, Guillem Jover wrote:
|update: since dpkg in etch, gnueabi-arm is pretty much the only choice.
Someone knows what does this mean?
In older dpkg you could just define any
"gcc -dumpmachine <-> dpkg-architecture" ma
I am told that the "choice of name" is the one thing that has
generated most heat and least light among the Debian EABIfiers - maybe
because it really doesn't matter, or maybe because it's the only thing
the technically weak feel competent to argue about... ;) Personally I
think "wendy" is a nice n
On Thu, Mar 30, 2006 at 03:40:40AM +0300, Guillem Jover wrote:
> |update: since dpkg in etch, gnueabi-arm is pretty much the only choice.
> Someone knows what does this mean?
In older dpkg you could just define any
"gcc -dumpmachine <-> dpkg-architecture" mapping in archtable.
dpkg-architectur
Hi,
At Nokia for the next 770 software update we are switching to EABI.
And using the same Debian arch name w/o changing lib names will make
it binary incompatible with Debian, which I'd hate to see. Thus even
if there's no plan for an upgrade path yet (although multi arch could
be the solution),
31 matches
Mail list logo
