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

[Charles Wilson]

Peter Rosin wrote:

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

Looks like there was also xerces-c, which is open-source but C++.  So,
the root of the problem might not, in fact, have to do with the
patchlevel revisions of the C runtime(s), but rather the MSVC C++
runtime(s).

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

Yes, that was what I was trying to convey.

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

Ok. However, that doesn't invalidate my point concerning the MS *C*
runtime major versions.  Because they change fairly often -- every year
or so -- much more often than *nix libc.so ABI changes.

Plus, you just don't DO that on *nix: mix different ABI versions of
libc.so on the same system. That sort of thing is reserved for major
distribution upgrades.  Yet, on windows, you will routinely have msvc70,
msvc71, msvc80 (31 flavors), msvcrt.dll, etc. all installed at the same
time.

However, it's probably very rare that even a developer will have more
than one version of MSVC installed on the same machine. Right? So maybe
it's a non-issue.

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

Okay...

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

Well, actually I *wasn't* advocating that $host reflect the MSVC8
patchlevel. I was just pointing out the (potential) problem --
unfortunately the whole discussion went straight to the tall weeds.

I *was* advocating that $host reflect the major revision (70, 71, 80).
And I still do, because those represent API changes -- behavioral, as
well as new interfaces added -- to the underlying C runtime in use.
Many triples specify "dietlibc" or "uclibc" vs "glibc", especially in
the embedded world.  I don't really see that this is different.

I also think that -winnt is too broad; and I'd really hate to see the
massive uglification of the libtool code -- and thousands of
configure.ac's out there -- that would ensue if -mingw* were
/officially/ overloaded to also represent the msvc-toolchain case.

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

Again, I just /mentioned/ the patchlevel issue. I'm only advocating that
the API level of the ms runtime be encoded in $host.  (Anything finer
grained is just as completely FUBARed^W difficult to manage as MS's
side-by-side "solution").

--
Chuck