MacOS.hpp and PowerPlant incompatibility
I am trying to use the boost libraries with a PowerPlant project on the
MacOS, and I ran into a small incompatibility between the headers. I am not
sure which codebase is at fault here.
The issue is with the __MACH__ symbol. In the Boost code where it is
checking for what platform I am using, it correctly identifies my platform
as MacOS. Then, in a file called MacOS.hpp, it uses the __MACH__ symbol to
determine if I am using the BSD standard C libraries or MSL. (I am using
MSL.)
It does this by checking for the EXISTANCE of the __MACH__ symbol, not
the value of it:
// If __MACH__, we're using the BSD standard C library, not the MSL:
#if defined(__MACH__)
However, in the PowerPlant header PP_Macros.h, the __MACH__ symbol is
defined and set to zero:
#ifndef __dest_os // For MSL
#ifndef __MACH__
#define __MACH__ 0
#endif
#if __MACH__
#include
I am trying to use the boost libraries with a PowerPlant project on the MacOS, and I ran into a small incompatibility between the headers. I am not sure which codebase is at fault here.
The issue is with the __MACH__ symbol. In the Boost code where it is checking for what platform I am using, it correctly identifies my platform as MacOS. Then, in a file called MacOS.hpp, it uses the __MACH__ symbol to determine if I am using the BSD standard C libraries or MSL. (I am using MSL.)
It does this by checking for the EXISTANCE of the __MACH__ symbol, not the value of it:
// If __MACH__, we're using the BSD standard C library, not the MSL: #if defined(__MACH__)
However, in the PowerPlant header PP_Macros.h, the __MACH__ symbol is defined and set to zero:
#ifndef __dest_os // For MSL
#ifndef __MACH__ #define __MACH__ 0 #endif
#if __MACH__ #include
#else #define __dest_os __mac_os #endif #endif I was able to work around the problem for now by making the Boost libraries check for both the existance of __MACH__ and the value:
#if defined(__MACH__) && __MACH__
Seems to work.
However, I am curious. Which way is the right way? Is the __MACH__ symbol's existance or its value supposed to signal whether or not it is "turned on"? The boost headers seem to think it is its existance, but the PowerPlant headers seem to think it is its value.
I want to report the problem, but I am not sure whose code needs to change, PowerPlant or Boost. Ideas?
Is PowerPlant a third party lib? If so then I don't think it should be setting a reserved symbol like __MACH__, however it's easy enough to change the boost code to verify that __MACH__ is greater than zero, so I'll make that change anyway unless there are objections (any Darwin experts out there?). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
on 6/6/02 7:17 AM, John Maddock at john_maddock@compuserve.com wrote:
I am trying to use the boost libraries with a PowerPlant project on the MacOS, and I ran into a small incompatibility between the headers. I am not sure which codebase is at fault here.
The issue is with the __MACH__ symbol. In the Boost code where it is checking for what platform I am using, it correctly identifies my platform as MacOS. Then, in a file called MacOS.hpp, it uses the __MACH__ symbol to determine if I am using the BSD standard C libraries or MSL. (I am using MSL.)
It does this by checking for the EXISTANCE of the __MACH__ symbol, not the value of it:
// If __MACH__, we're using the BSD standard C library, not the MSL: #if defined(__MACH__)
However, in the PowerPlant header PP_Macros.h, the __MACH__ symbol is defined and set to zero:
#ifndef __dest_os // For MSL
#ifndef __MACH__ #define __MACH__ 0 #endif
#if __MACH__ #include
#else #define __dest_os __mac_os #endif #endif I was able to work around the problem for now by making the Boost libraries check for both the existance of __MACH__ and the value:
#if defined(__MACH__) && __MACH__
Seems to work.
However, I am curious. Which way is the right way? Is the __MACH__ symbol's existance or its value supposed to signal whether or not it is "turned on"? The boost headers seem to think it is its existance, but the PowerPlant headers seem to think it is its value.
I want to report the problem, but I am not sure whose code needs to change, PowerPlant or Boost. Ideas?
Is PowerPlant a third party lib? If so then I don't think it should be setting a reserved symbol like __MACH__, however it's easy enough to change the boost code to verify that __MACH__ is greater than zero, so I'll make that change anyway unless there are objections (any Darwin experts out there?).
John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
PowerPlant is Metrowerks application framework for Mac OS. One of the changes with Codewarrior 8 was the ability to use MSL or Apple's C library when building mach-o targets. Apple's native headers only check if __MACH__ is defined but they will only be used when __MACH__ is simply defined or is 0 so the change in the PowerPlant header file is benign if slightly unexpected. Chris
PowerPlant is Metrowerks application framework for Mac OS. One of the changes with Codewarrior 8 was the ability to use MSL or Apple's C library when building mach-o targets.
Apple's native headers only check if __MACH__ is defined but they will only be used when __MACH__ is simply defined or is 0 so the change in the PowerPlant header file is benign if slightly unexpected.
OK, so I guess Metrowerks can argue that they "own" that symbol, whatever we should fix boost's headers so that they'll cope with this (in fact I see that Darin has done so already). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
on 6/6/02 6:17 AM, John Maddock at john_maddock@compuserve.com wrote:
Is PowerPlant a third party lib? If so then I don't think it should be setting a reserved symbol like __MACH__, however it's easy enough to change the boost code to verify that __MACH__ is greater than zero, so I'll make that change anyway unless there are objections (any Darwin experts out there?).
PowerPlant is an application framework written by Metrowerks and distributed with CodeWarrior. It is a very widely used framework in the Mac world (probably as widely used as MFC is on Windows). FWIW that was my first thought too - why are they even defining this? But if Mac programmers are going to try to use Boost, keeping it compatible with PowerPlant is a good idea. (I'll be sure and post about any other issues I find - so far this is the only one!) I got an interesting response when I posted this same question to the Metrowerks newsgroup, from a MW employee. The comment before the test says it is trying to determine whether BSD or MSL libraries are being used. CodeWarrior Pro 8 allows you to choose either MSL or BSD standard library implementations in Mach-O binaries, so testing for __MACH__ will no longer be a sufficient test. (The following commented section was originally posted to the comp.sys.mac.programmer.codewarrior newsgroup by Josef W. Wankerl of Metrowerks):
That may have worked with Pro 7, since it was true that whenever __MACH__ was defined, the BSD headers and libraries were being used.
For Pro 8, that's changed since you now have the option to use MSL C. The test should be something like:
#if __MACH__ #include
/* Get __MSL__ and _MSL_USING_MW_C_HEADERS */ #if (__MSL__ >= 0x8000) && _MSL_USING_MW_C_HEADERS /* MSL C is being used */ #else /* BSD C is being used */ #endif #endif
As a further bit of clarification to the above code - the test (__MSL__ >= 0x8000) is testing for the version of the MSL libraries - it only tests for using MSL headers with Mach on Pro 8 or later, because that is when it was added. -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------
On Tuesday, June 4, 2002, at 07:16 AM, Bobby Thomale wrote:
However, in the PowerPlant header PP_Macros.h, the __MACH__ symbol is defined and set to zero:
OK. This is probably a minor mistake on Metrowerks' part, but it's reasonable, and not a big deal.
I was able to work around the problem for now by making the Boost libraries check for both the existance of __MACH__ and the value:
#if defined(__MACH__) && __MACH__
Seems to work.
Yes, I'd recommend that we change Boost to do the check this way. But it should be abbreviated to: #if __MACH__ The C and C++ standards guarantee that works properly with an undefined symbol. I'm going to make this change in cvs.
However, I am curious. Which way is the right way? Is the __MACH__ symbol's existance or its value supposed to signal whether or not it is "turned on"? The boost headers seem to think it is its existance, but the PowerPlant headers seem to think it is its value.
I want to report the problem, but I am not sure whose code needs to change, PowerPlant or Boost. Ideas?
Boost should change. I have no idea whether the PowerPlant thing is a bug or not, but we should just fix both sides. -- Darin
participants (4)
-
Bobby Thomale
-
Chris Little
-
Darin Adler
-
John Maddock