> > Markus Duft skrev: > >> I Forgot to answer some things... > >> > > <snip> > >> My patches use the same host/build as MinGW when using MSYS, on the > >> grounds that the output from the MinGW tools and MSVC are compatible > >> (so same $host) and that MSYS is MSYS (same $build). That's also > >> how cccl has it (at least I think so...) > > > > Hmm.. but your compiler is a different one, and thus behaves > different than > > mingw. I don't think it's a good idea to take the mingw triplet for > > something other than mingw. Who knows - if there is something out > there that > > is capable of patching mingw binaries in some form, relying on code > that > > only gcc creates (I know that sample is kind of unrealistic, but hey > - I > > patch MSVC binary code ;)) - it would fail with you binaries. > > Then I think you are reading too much into the host triplet, it denotes > hardware-vendor-os (and possibly -libc appended). There is no info in > there that helps you determine the compiler.
Hm, yeah, right :) > > >>>>> The winnt was just the best that came to our ming, > since > >>>> the > >>>>> result is plain win32 binaries. > >> "winnt" is not the only kind of output from MSVC. So, why is winnt > >> better than win9x/winxp/win2k3 or whatever? And other tools also > >> target winnt. To sum it up, I think winnt is both too narrow and > >> too broad to be used as $host. Why not just parity? > > > > I don't support the 9x series of windows, and everything else is NT- > kernel > > based, so I think winnt denotes all of NT4, 2000, XP, 2003, 2003R2, > Vista > > and 2008 - that's what I intend. > > Ok, but MinGW is also winnt. (If you stretch it a bit, Cygwin is also > winnt > for that matter, but that's a different libc.) > > >> If you want to have a common name, mingw is it, that's what's used > >> to denote the win32 environment w/o compatibility layers. If you > >> want to go your own way, winnt is too generic. > > > > IMHO mingw produces code that is very different from what MSVC > produces - > > not only performance wise (in some cases). > > I don't think that matters when it comes to the $host triplet, you can > link code from MinGW with code from MSVC. Same os, same libc. Not necessarily same libc. Same kernel only. As you say below, mingw uses msvcrt.dll, which is the windows _internal only_ libc (MSDN: "The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components."). this means, that not a single windows "default" user can link against it. I guess mingw provides an import library for it, or ld can handle the dll directly without import lib. However it's in no way a setup you can get without mingw that easy (although - of course - msvcrt.dll may be loaded and used through LoadLibrary, even if another msvc??.dll is linked in). This means, that mingw is _not_ what the windows compilers/linkers will produce by default - I found quite big differences from msvcrt.dll and msvc80.dll for example. It's nothing else but _compatible_ with winnt. Phew.. getting headaches now too (again...) :) > > > Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this > > describes (in the same form as on linux) which platform I'm on. > Parity as > > platform would be a little bit misleading I guess, since I want > everyone to > > see on the first look that those binaries are native windows, and > nothing > > else. > > MinGW binaries are also native Windows binaries, and nothing else. I > agree > that -parity as "-os" is bad, but since the only reason for you to add > a > new -os is to make it simple for you (i.e. easy to test in configure > and > libtool, no cross compiles when using interix as $build etc), I think > -parity is the best fit. I don't agree here. I think winnt ist the best match, since (opposed to mingw) I really use all the libraries and such exactly the same as the native compiler/linker... > > However, i686-pc-mingw32 is perhaps not correct for Microsoft compilers > other than MSVC 6, since they use a different libc. It might also be > incorrect for MSVC 6 w/o the -MD option since then you are also using a > different libc than MinGW (i.e. msvcrt.dll). Ok, maybe correct for MSVC6, but come one... :) this is stone-age. From todays POV it's no more than compatible, and even this is questionable, because mixing heap managers can be dangerous. What if a mingw dll allocates memory using msvcrt.dll, passes the pointer to an executable built with native linker, and this free's using msvc80.dll - or the other way round. I had such problems when I started out with parity. Believe me, they are no fun to hunt down ;) Cheers, Markus > > I'm getting a headache... > > Cheers, > Peter
