Re: dpkg-architecture adaptations for e.g. uclibc
Volker Grabsch wrote:
> On Mon, Jun 12, 2006 at 04:32:16PM +0200, Pjotr Kourzanov wrote:
>> I have not investigated this further but it looks like the mingw32 package
>> requires a patch so that it generates cross versions for w32-i386 (GNU: i486-mingw32msvc), and
>> not i586-mingw32msvc.
>
> I already discussed this point with the author. Maybe "w32-i386" is a
> bad name, and "w32-i586" would be more accurate
My guess would be that the binaries you get from M$ are optimized for i586 right?
file on /usr/i586-mingw32msvc/lib/crt1.o says "80386 COFF executable not stripped - version 30821",
What's the target CPU for the wrappers in mingw32-runtime?
.
>
> However, there's no sense in compiling win32 applications for anything
> lower than Pentium, so why should we throw those optimizations away?
> The only exception may be some very rare 486 machines with Windows 95
> installed on them.
>
> (for a Linux system, however, a 486 machine of course makes a lot more
> sense)
>
>> The only correct CPU for Debian is AFAIK i386, which gets translated to i486 GNU CPU. So,
>> my guess would be to add w32 to ostable and re-compile mingw32 package to use w32-i386 (and thus
>> i486-mingw32msvc).
>
> That means, it should be called "w32-i586" instead, which is perfectly
> okay for me.
>
>> My patch adresses a different problem of allowing CPU-ABI, CPU-LIBC, OS-CPU-LIBC, OS-CPU-ABI
>> and CPU-CPU-LIBC-ABI schemes.
>> Supposing that people are willing to split mingw32msvc into
>> OS=w32, LIBC=msvc and ABI=ming, the mapping for my dpkg-architecture version would become
>> w32-i386-msvc-ming (GNU: i486-w32-msvc-ming), which IMHO would make more sense than i586-mingw32msvc.
>
> This sounds reasonable. BTW, why do you call it "ming" instead of "mingw"?
w from mingw is from w32 no? So, it's Minimalist GNU for w32, so I suppose w32 would be an OS,
msvc would be LIBC, and ming would be sortof ABI used with w32-msvc.
>
> Also, for every architecture, there are some defaults for the LIBC and ABI.
> For w32, msvc and mingw is a very good default for various reasons. Does
> your naming sheme allow that? (i.e. making w32-i386 equivalent to
> w32-i386-msvc-ming) Or are there only overall defaults for LIBC and ABI
> for all architectures?
There is a mapping in the ostable (e.g. linux-> linux-gnu). I see no entry for w32
there though, but you could add something like "w32 w32-msvc-ming pc-mingw32" as well as
"w32-cygnus w32-msvc-cygnus pc-cygwin" or something like that.
>
>
> BTW, I also heard about people who compiled a whole (Debian
> based) system for i586 to increase the overall performance of their
> system. They, too, had the same problem: How to name this
> architecture/cpu? As far as I could see, they "solved" that problem by
> adding a "pentium" line (or similar, AFAIR) to their cputable.
>
> That having said, I don't think it isn't the question whether one
> wants to compile for i586, i686, etc. There are always good reasons
> for some groups to do so. IMHO, the more important question is how to
> name that thing. So it would be very nice if dpkg-architecture would
> be flexible enough to support that, instead of stepping in the way.
There are several alternatives, all of which have little to do with dpkg-architecture.
1. add a specific CPU to cputable and use that to compile all packages
(I used to do that for ARMv4 and ARMv5te). This might not be acceptable in Debian.
2. create a separate repository with optimized binaries but still targeting i386 (or arm).
3. for some packages create optimized versions with CPU embedded in the name such as
mplayer-i586.
I think the problematic part would be in apt or dpkg, where a decision would need to be
made from where and which packages to install.
>
>
> Greets,
>
> Volker
>
Pjotr
Reply to: