Yesterday I was trying to help my wife get the Boost libraries to compile in her application. It reminded me of an issue I thought I brought up a while ago (maybe I forgot) that still exists in the boost Macos.hpp config file. In the MacOS.hpp file, it checks to see if you are compiling a Mach-O target. If you are, it reasons, you must be using the Apple BSD headers as well. This logic is even documented in a comment: // If __MACH__, we're using the BSD standard C library, not the MSL: #if __MACH__ The problem with this is that, starting with CW Pro 8, it is actually possible to build a Mach-O target and use the MSL in place of the BSD libraries. Lots of people are apparently doing this, including my wife. (I am still on CFM and have not made the transition to Mach-o yet, but I will eventually and I will potentially be in the same boat. The newer Carbon APIs are Mach-o only so that is where all the carbon programmers will eventually go, and as long as Codewarrior is around, MSL will be there as an option for people.) There are also people who use other STL implementations, such as STLPORT. When it defines all of the stuff it does in there, for the BSD libraries, the mach-o MSL code does not compile. Instead, I get hundreds of compile errors. The only way I could get this to compile for her was to force it to use the TARGET_CARBON stuff at the bottom, after the #else (meaning "not mach-o"), by commenting the __MACH__ stuff out. Obviously, that was a "see if this is really her problem" solution, also to get her up and running, and not a long-term fix. :-) It worked by the way. The config.hpp stuff seperates out your platform settings from your standard library settings. Is there a reason that standard library implementation-specific settings are being set by platform and binary format? If there is magic that needs to happen that is specific to Apple's BSD headers, shouldn't there maybe be a "BSD.hpp" or even "AppleBSD.hpp" for BOOST_STDLIB_CONFIG instead? Or am I missing something? Anyway. That is just a question/suggestion, take it or leave it. It makes sense that the TARGET_CARBON stuff at the bottom is platform specific, but the stuff above it seems like it should go somewhere else. In any case, whether that stuff is moved or not, something needs to change to alleviate the pain for those using Mach-o and MSL together, because right now boost is broken for those users. (Am I reporting this to the right list by the way?) -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------
on 10/23/02 10:48 AM, Bobby Thomale at bobby-thomale@mail.inoveon.org wrote:
Yesterday I was trying to help my wife get the Boost libraries to compile in her application. It reminded me of an issue I thought I brought up a while ago (maybe I forgot) that still exists in the boost Macos.hpp config file.
In the MacOS.hpp file, it checks to see if you are compiling a Mach-O target. If you are, it reasons, you must be using the Apple BSD headers as well. This logic is even documented in a comment:
// If __MACH__, we're using the BSD standard C library, not the MSL: #if __MACH__
The problem with this is that, starting with CW Pro 8, it is actually possible to build a Mach-O target and use the MSL in place of the BSD libraries. Lots of people are apparently doing this, including my wife. (I am still on CFM and have not made the transition to Mach-o yet, but I will eventually and I will potentially be in the same boat. The newer Carbon APIs are Mach-o only so that is where all the carbon programmers will eventually go, and as long as Codewarrior is around, MSL will be there as an option for people.)
Bobby, 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. I'll submit a patch so this will be fixed in an upcoming build. Chris
On Wednesday, October 23, 2002, at 08:57 AM, Chris Little wrote:
Change the line to
#if defined(__MACH__) && __MACH__
How does that help if you are using Metrowerks' MSL and Mach-O? That doesn't sound like a solution. -- Darin
on 10/23/02 2:20 PM, Darin Adler at darin@bentspoon.com wrote:
On Wednesday, October 23, 2002, at 08:57 AM, Chris Little wrote:
Change the line to
#if defined(__MACH__) && __MACH__
How does that help if you are using Metrowerks' MSL and Mach-O? That doesn't sound like a solution.
You're right it's not. I answered too soon and was side tracked by the discussion of this problem in June. For CWP8 it looks like the line should be #if __MACH__ && !defined(_MSL_USING_MSL_C) 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. Chris
On Wednesday, October 23, 2002, at 01:06 PM, Chris Little 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.
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. -- Darin
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/ ---------------------------------------------------------------------
On Wednesday, October 23, 2002, at 07:48 AM, Bobby Thomale wrote:
In the MacOS.hpp file, it checks to see if you are compiling a Mach-O target. If you are, it reasons, you must be using the Apple BSD headers as well. This logic is even documented in a comment:
// If __MACH__, we're using the BSD standard C library, not the MSL: #if __MACH__
The problem with this is that, starting with CW Pro 8, it is actually possible to build a Mach-O target and use the MSL in place of the BSD libraries.
OK, I'll be happy to fix this. The check for __MACH__ was simply to echo what Metrowerks themselves did in CodeWarrior Pro 7, and it hasn't yet been updated for CodeWarrior Pro 8. How can we detect which version of the C standard library headers are being used at compile time? We want something that works for both Pro 7 and Pro 8.
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. -- Darin
participants (3)
-
Bobby Thomale -
Chris Little -
Darin Adler