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

[Peter Rosin]

Duft Markus skrev:
> > 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.

You  can have different C++ mangling on other systems too, and I still
suspect $host to be the same. But this I don't know for a fact though.

> Yeah, that's what i'm talking about :) mingw != winnt. Period.

On the contrary, I would say that mingw is indeed winnt since
Microsoft has declared msvcrt to be owned by the operating system.
I.e. winnt.

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

That may not work, if Charles statements about dlls requiring different
patchlevels of msvcr80 holds. But that appears to not be the case:

I created a simple dll, exporting one function doing a printf (some random
libc function). When building this dll, MSVC8 generated a manifest, but I
instead embedded the manifest pointing to an older msvcr80.

I.e. Embedded this:

<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' 
version='8.0.50608.0' processorArchitecture='x86' 
publicKeyToken='1fc8b3b9a1e18e3b' />

instead of what MSVC8 generated, which was this:

<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' 
version='8.0.50727.762' processorArchitecture='x86' 
publicKeyToken='1fc8b3b9a1e18e3b' />

Then I created an exe using both fopen (some other libc function) and
consuming this dll, and in that exe I embedded the generated manifest
(i.e. version 8.0.50727.762). Looking at this exe with depends.exe
reveals that only one msvcr80.dll is loaded. That might be a bug in
depends.exe though.

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

Yes, it is handled by libtool. Though, libtool will currently not
embed manifests in built dlls, only exes. Maybe dlls also need
to have the manifest embedded, but I have not needed that yet...

Cheers,
Peter