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