> > Markus Duft wrote: > > IMHO mingw produces code that is very different from what MSVC > produces - > > not only performance wise (in some cases). > > And remember, you can only link code generated by mingw and by msvc > together if you're using C. Not C++ or any other symbol-mangled ABI. > PLUS, if you're talking about shared libraries (DLLs explicitly encode > the libc that they depend on), you also can only use DLLs in the same > app that depend on the same mxvcrt -- that is, msvcrt.dll. Not > msvcrt71.dll etc.
Yeah, that's what i'm talking about :) mingw != winnt. Period. > > > 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. > > I've been using *-*-msvcXX to designate microsoft compiler-based host > triples. So, for Visual C++ 2005, it's -msvc80. I was just thinking about something quite similar. I though about renaming my *-winnt to *-winnt-parity, and suggest peter to use *-winnt-msvc. Maybe the runtime version would be required too for both of them... > > This really saved our bacon at work when we switched from VizStudio > 2003 > to 2005; the different host triple allowed us to keep old/new stuff > separate which was important during the transition, as they couldn't be > linked together due to the different runtime requirements. (Plus, the > 2003 stuff didn't need any of that .manifest crap, and couldn't > understand it anyway, while it was required for the 2005 stuff). > > I suspect libtool will have to deal with this too -- wouldn't it be > good > have the .manifest-related code active only when -msvc80 or above? As for parity, the manifest handling is built-in, no need to worry about this. Parity can be used exactly the same for all of VS2003, VS2005, VS2008 and VS2008 Express Editions (attention: _not_ VS2005 Express Edition, except with some hacking :)) But maybe this is something peter has to handle in libtool? Cheers, Markus > > -- > Chuck >
