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: Charles Wilson
Subject: Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Date: Mon, 25 Aug 2008 07:22:14 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666

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.

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

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?

--
Chuck




reply via email to

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