Cool ... results ... :-) I love how responsive the Boost community is. Have I mentioned lately that you guys rock? I am replying to this whole thing at once. Chris Little wrote:
Change the line to
#if defined(__MACH__) && __MACH__
This was talked about in June on this list and I thought someone had submitted a patch but I guess not. I'm still building CFM apps so I hadn't noticed.
Yep. That was me, too, that started that discussion. The original line was #ifdef __MACH__. I suggested the above, then someone else (Darin I think) pointed out that #if __MACH__ does the same thing and is shorter. :-) #if __MACH__ is what it does now, that is equivalent to your above line. So that was a different problem which is solved. (Looks like you guys already figured that out later in the discussion...) Then Darin Adler wrote:
OK, I'll be happy to fix this.
That's great. Again, thanks for being so responsive guys!
There are also people who use other STL implementations, such as STLPORT.
It doesn't really matter which STL implementation you are using. The stuff in macos.hpp is for the C standard library. MSL C, not MSL C++. The STL is part of the C++ library, and that's handled by msl.hpp, etc. While there may be a problem there, it's not the same one you mention above.
Sure. I was just giving a for-instance, I am not actually using STLPORT or know of any probs with it. I think I understand what you are saying though. In the "BOOST_STDLIB_CONFIG" macros and files, "STDLIB" means "The Standard C++ Libraries (STL) only" and not "The Standard C/C++ Libraries." Got it - that wasn't obvious to me. So if someone were using STLPORT, for instance, that doesn't replace your standard C libs too - it is just a C++ STL implementation built on top of whatever C libs you happen to be using? Very interesting and cool. My confusion was partly because I wasn't sure what you guys meant by "STDLIB" and also because CW always tended to lump the standard C libraries, and their C++ STL stuff all together into one big set of libraries, and call it one name. I haven't actually tried STLPORT or any of the other third party STL libs, I was assuming they replaced all of your standard libraries, not just the C++ portion. Now that I think about it, though, that'd require them to chase platform changes, which would be abstracted for them by the C libraries. The C libs tend to be a platform specific abstraction layer, which is why C library stuff for Boost goes in a "platform" file not "STDLIB." Got it. Makes perfect sense now. Thanks! Later Darin wrote:
For CWP8 it looks like the line should be
#if __MACH__ && !defined(_MSL_USING_MSL_C)
That will work for CodeWarrior Pro 7 too, because _MSL_USING_MSL_C won't be defined under 7. I'll take care of it.
Sounds like a good fix. I will get Jessica to try it out. I'm sending it to her now - it should do the trick.
I'm not sure what to do for CWP7 though. Now that I'm running Jaguar (and thus gcc 3.1) CWP7 can't even build a simple mach-o console app due to conflicts in standard library headers.
Sure, that's a problem. It's too bad that CodeWarrior Pro 7 is not compatible with Jaguar. But nothing for Boost to worry about.
Yep - the MW party line on Jaguar problems is "Upgrade to CW Pro 8." -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------