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

[Peter Rosin]

Charles Wilson skrev:
> Peter Rosin wrote:
> > 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.
>
> [snip]
>
> > 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.
>
> In a non-toy application, consisting of a dozen different open-source C
> libraries, thirty or more proprietary libraries comprising about 250k
> lines of C++ code, and a handful of applications, we ran into
> significant issues when developer A built the open source libraries with
> MSVC 2005 patchlevel X, and developer B linked the application(s) using,
> and where our proprietary code was compiled with, his MSVC 2005
> patchlevel Y.  The apps crashed badly.  These problems went away when
> everything -- including C open-source libraries -- were all compiled
> with the same patchlevel compiler, with no other changes.

Do you remember if anything C++ was built with the offending patchlevel?
Or was it the "open-source C libraries" and nothing else that was built
differently?

> > 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...
>
> VisStudio does embed manifests in the DLLs AFAICT. However, this /may/
> not be necessary, and perhaps I should try turning that off.  Then, the
> only items in my on-the-job work that would actually specify which
> patchlevel/runtime should be loaded would be the application itself.

Not embedding the manifest might be dangerous as the inline/dll
boundary might have changed with a new patchlevel. Yes, I'm
speculating. Just a word of caution...

> As long as there's no conflict (for C++) between inline code taken from
> the STL headers of patchlevel X, and the non-inline code dynamically
> linked at runtime from the msvcp80.dll of patchlevel Y. (Note here I'm
> specifically talking about the C++ runtime, but similar
> inline/vs/out-of-line concerns probably hold for the C runtime of
> doffering patchlevels).
>
> Only experimentation will tell.

You might compare the situation to the compatibility problems with
different g++ major versions. The g++ major version is not reflected
in $host, and that's a considerably more stable number...

So, I think we need to find out if the MSVC patchlevel influences the
libc compatibility. I.e. ignore C++ for this discussion, as C++ has a
whole new set of incompatibility possibilities that are already
ignored elsewhere...

Hmmm, just taking a step back here, changing $host to reflect the MSVC8
patchlevel is going to resolve these issues how, exactly?

I mean if you pick up a prebuilt dll somewhere and mindlessly link with
it, it's not unlikely that you're SOL in any case. There is no way to
keep the user isolated from this mess, so when will it help to add the
MSVC8 patchlevel to $host?

Cheers,
Peter