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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
