libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [patch #6448] [MSVC 7/7] Add MSVC Support


From: Duft Markus
Subject: RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Date: Mon, 25 Aug 2008 13:52:56 +0200

> 
> 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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]