MS compiler detection
Hi! I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them. I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical: MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200 Some other changes were that I corrected a few comments that spoke of only VC6, but there are too many of them - I didn't get them all. Another change was that I prepared the autolinking feature for evc4. I tested the changes on a mirror of CVS from 6 months ago, and so far it seems to work with evc4, vc6 and vc7.1. BTW-1: I also noticed the same problem with other compilers/versions, i.e. there are checks like 'MSC_VER > 1310' targeting VC8. This will fail if there comes a service pack with a compiler with version 13.11, not an acute problem though, just something to keep in mind perhaps. BTW-2: There are a few cases where the compiler version was used to check for a feature of the standardlibrary some variants of it came bundled with. I think I marked these places with a 'TODO' tag. For all who wonder, there is no real standardlibrary shipped with evc4, neither a C nor a C++ one. STLport is mandatory therefore. Also, the functions of the win32 API that use TCHAR=char are also almost gone, but those are another patch another day. A last thing is that when linking, the name of the lib must not be larger than 32 chars, or the runtime linker won't be able to find the lib. Explicit loading with LoadLibrary still works. Guess how much blood, sweat&tears it took me to find out ... the threads lib which is the only one I need is 33 chars or somesuch. Please commit these changes, they are easy to verify and nonintrusive for unaffected compilers, thanks. Uli
I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them.
I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical:
My mistake, I think I promised to apply that, but never got around to it.
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200
That last one is wrong, I assume you meant to type: MSC_VER >= 1200 -> MSC_VER > 1200
Some other changes were that I corrected a few comments that spoke of only VC6, but there are too many of them - I didn't get them all. Another change was that I prepared the autolinking feature for evc4.
The autolink changes look OK, but do they they match the names that bjam produces (assuming you can compile at all with bjam with eVC++)? The changes to visualc.hpp have some misplaced #errors in there, in fact I don't think we should be adding #errors at all just because we can't define a meaningful BOOST_COMPILER macro (the macro is only for informative use after all). I spotted a mistake in RCS file: /cvsroot/boost/boost/boost/mpl/aux_/numeric_op.hpp,v - && BOOST_WORKAROUND(BOOST_MSVC, != 1200) + && BOOST_WORKAROUND(BOOST_MSVC, < 1300) should be: - && BOOST_WORKAROUND(BOOST_MSVC, != 1200) + && BOOST_WORKAROUND(BOOST_MSVC, >= 1300) In RCS file: /cvsroot/boost/boost/more/microsoft_vcpp.html,v The additions: +<tr> +<td>Microsoft Visual C++ 7.0 </td> +<td>1300</td> +</tr> + +<tr> +<td>Microsoft Visual C++ 7.1 </td> +<td>1310</td> +</tr> + Shouldn't be there (since the document describes bugs found in VC6 only). Other than that the changes all look OK to me. Doug, is it too close to release to apply blanket changes like this? I'm guessing that if they cause any problems they should show up PDQ. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them.
I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical:
My mistake, I think I promised to apply that, but never got around to it.
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200
That last one is wrong,
They're all wrong (missing leading underscore on _MSC_VER) ;-)
I assume you meant to type:
MSC_VER >= 1200 -> MSC_VER > 1200
No, that doesn't make sense either. It changes semantics for versions of _MSC_VER that were known to us before Ulrich pointed out the existence of 1202. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jul 10, 2005, at 5:13 AM, John Maddock wrote:
I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them.
I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical:
My mistake, I think I promised to apply that, but never got around to it.
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200
That last one is wrong, I assume you meant to type:
MSC_VER >= 1200 -> MSC_VER > 1200
Some other changes were that I corrected a few comments that spoke of only VC6, but there are too many of them - I didn't get them all. Another change was that I prepared the autolinking feature for evc4.
The autolink changes look OK, but do they they match the names that bjam produces (assuming you can compile at all with bjam with eVC++)?
The changes to visualc.hpp have some misplaced #errors in there, in fact I don't think we should be adding #errors at all just because we can't define a meaningful BOOST_COMPILER macro (the macro is only for informative use after all).
I spotted a mistake in
RCS file: /cvsroot/boost/boost/boost/mpl/aux_/numeric_op.hpp,v
- && BOOST_WORKAROUND(BOOST_MSVC, != 1200) + && BOOST_WORKAROUND(BOOST_MSVC, < 1300)
should be:
- && BOOST_WORKAROUND(BOOST_MSVC, != 1200) + && BOOST_WORKAROUND(BOOST_MSVC, >= 1300)
In
RCS file: /cvsroot/boost/boost/more/microsoft_vcpp.html,v
The additions:
+<tr> +<td>Microsoft Visual C++ 7.0 </td> +<td>1300</td> +</tr> + +<tr> +<td>Microsoft Visual C++ 7.1 </td> +<td>1310</td> +</tr> +
Shouldn't be there (since the document describes bugs found in VC6 only).
Other than that the changes all look OK to me.
Doug, is it too close to release to apply blanket changes like this? I'm guessing that if they cause any problems they should show up PDQ.
It's really too late for this kind of far-reaching change. Any breakage with this patch will mean that we'll have to revert it, and it will cost us about 3 days given the current regression-test turnaround time. However, if someone can verify that there are no new regressions on VC 6.0, 7.0, and 7.1 before committing the patch, I'll allow it. Doug
It's really too late for this kind of far-reaching change. Any breakage with this patch will mean that we'll have to revert it, and it will cost us about 3 days given the current regression-test turnaround time. However, if someone can verify that there are no new regressions on VC 6.0, 7.0, and 7.1 before committing the patch, I'll allow it.
Fair point, unfortunately I no longer have the disk space available on my laptop to run all the tests (!) so someone else will have to verify it if they want it to be committed. Looks like I've put off that hard drive upgrade for too long.... John.
On Jul 11, 2005, at 4:58 AM, John Maddock wrote:
It's really too late for this kind of far-reaching change. Any breakage with this patch will mean that we'll have to revert it, and it will cost us about 3 days given the current regression-test turnaround time. However, if someone can verify that there are no new regressions on VC 6.0, 7.0, and 7.1 before committing the patch, I'll allow it.
Fair point, unfortunately I no longer have the disk space available on my laptop to run all the tests (!) so someone else will have to verify it if they want it to be committed. Looks like I've put off that hard drive upgrade for too long....
You pointed out on or two errors in the patch; can someone post a revised patch? Doug
On Monday 11 July 2005 14:22, Douglas Gregor wrote:
You pointed out on or two errors in the patch; can someone post a revised patch?
Here we go. Also, I took another look at what changes I did, and there were only these three (I got them messed up last time): MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER > 1200 -> MSC_VER >= 1300 MSC_VER == 1200 -> MSC_VER < 1300 Uli
From: Ulrich Eckhardt <uli@doommachine.dyndns.org>
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER > 1200 -> MSC_VER >= 1300 MSC_VER == 1200 -> MSC_VER < 1300
I have no idea if this is important, but the last one clearly stands out. Is it intentional that all versions less than 1300 should match for those previous cases in which exactly version 1200 was to match? IOW, should the last case be the following? _MSC_VER >= 1200 && _MSC_VER < 1300 As I typed that, I recall having read that "MSC_VER" was supposed to have been "_MSC_VER." Did you miss that in your patch? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
MSC_VER == 1200 -> MSC_VER < 1300
I have no idea if this is important, but the last one clearly stands out. Is it intentional that all versions less than 1300 should match for those previous cases in which exactly version 1200 was to match? IOW, should the last case be the following?
_MSC_VER >= 1200 && _MSC_VER < 1300
It doesn't matter. We don't support VC 5. Nobody does.
Rob Stewart <stewart@sig.com> writes:
From: Ulrich Eckhardt <uli@doommachine.dyndns.org>
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER > 1200 -> MSC_VER >= 1300 MSC_VER == 1200 -> MSC_VER < 1300
I have no idea if this is important, but the last one clearly stands out. Is it intentional that all versions less than 1300 should match for those previous cases in which exactly version 1200 was to match?
We never supported versions before 1200, so that's really equivalent as far as Boost is concerned.
IOW, should the last case be the following?
_MSC_VER >= 1200 && _MSC_VER < 1300
As I typed that, I recall having read that "MSC_VER" was supposed to have been "_MSC_VER." Did you miss that in your patch?
heh, I pointed it out too, but nobody heard ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Monday 11 July 2005 23:00, Rob Stewart wrote:
From: Ulrich Eckhardt <uli@doommachine.dyndns.org>
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER > 1200 -> MSC_VER >= 1300 MSC_VER == 1200 -> MSC_VER < 1300
I have no idea if this is important, but the last one clearly stands out. Is it intentional that all versions less than 1300 should match for those previous cases in which exactly version 1200 was to match? IOW, should the last case be the following?
_MSC_VER >= 1200 && _MSC_VER < 1300
Yes, as someone already said, cl.exe v11.xx aka VC5 or before are so far away from C++ to be unsupported by boost anyway.
As I typed that, I recall having read that "MSC_VER" was supposed to have been "_MSC_VER." Did you miss that in your patch?
No. It's also missing the BOOST_WORKAROUND() or #ifdef or whatever, this is only pseudocode. To be honest, I didn't take the pointing out of this as a serious comment, as such an error in real code is far too quickly revealed by the compiler. Uli
On Sunday 10 July 2005 12:13, John Maddock wrote:
I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them.
I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical:
My mistake, I think I promised to apply that, but never got around to it.
Maybe also mine, as I didn't separate changes in a clear way - the compiler detection is just one of a few steps. Others have to do with the different native API, the restricted C standardlibrary and the disastrous C++ standardlibrary.
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200
That last one is wrong, I assume you meant to type:
MSC_VER >= 1200 -> MSC_VER > 1200
I don't exactly remember what I was thinking, but I hope the changes are more right than this thinko. Thank you for proofreading.
Some other changes were that I corrected a few comments that spoke of only VC6, but there are too many of them - I didn't get them all. Another change was that I prepared the autolinking feature for evc4.
The autolink changes look OK, but do they they match the names that bjam produces (assuming you can compile at all with bjam with eVC++)?
No, preparing bjam or boost-build is another set of necessary changes, I just prepared the name-tag("evc4"). One problem with bjam is that the compilers all have different names like clmips.exe for the MIPS targets. However, this is reflected in the %CC% environment var after running the appropriate batch file, so the situation is not that bad. Another thing is that evc4 is a cross-compile environment. In fact I had boost build v1 patched so that one could compile for a limited set of targets, but it was pretty messy. Also, v1 seems to be mostly dead, so I was told to use v2, which was too much work at that time - I simply created a project-file for the eVC IDE that built the threads lib and was fine with it. Another problem is the fact that the runtime linker silently and mysteriously fails to find DLLs whose name is more than 32 characters and libboost_thread-evc4-mt-gdp-1.32.dll is just a few characters too large. Since evc4 offers no choice between singlethreaded and multithreaded, I'd just drop that '-mt', that way at least (didn't try others) the threads library works. I'll post more patches on the other necessary changes later. Uli
participants (6)
-
David Abrahams -
Douglas Gregor -
John Maddock -
Peter Dimov -
Rob Stewart -
Ulrich Eckhardt