We still build our older toolkit with CW on PPC macs and recently
upgraded to Xcode 2.4. When rebuilding the CW libraries and
pre-compiled headers we got an error:
CodeWarrior gives a "type cannot be made with a global register
variable" error about the __asm("_scalb$UNIX2003" ) construct on line
647 of math.h in Xcode 2.4. I show the relevant lines of math.h from
2.3 and 2.4 below. Although the BuildLibraries.mcp projects built, when
I tried to build the
Build.MacOSX.mcp->BuildMacOSXSupport.mcp->MacHeadersMach-O.mcp
precompiled headers, it gave the math.h error about 18 times. This did
not stop the rest of the build, but that may be because I already had
libraries.
We are running MacOS 10.4.7 on a G5 iMac.
Anyone seen this? Have a fix? It would be nice if Apple kept stuff out
of the standard headers that broke other compilers (obsolete or not).
math.h 2.3
#if __DARWIN_UNIX03
extern double scalb ( double, double ) __DARWIN_ALIAS(scalb); /*
UNIX03 legacy signature */
#else
extern double scalb ( double, int ); /* Mac OS X legacy signature */
#endif /* __DARWIN_UNIX03 */
-----
math.h 2.3
/*
* Scalb Travellers' advisory:
* ---------------------------
*
* Reduction of Information advisory -- This advisory may constitute
"too much information". Readers who are easily panicked
* or confused may be needlessly
panicked or confused by this advisory.
*
* We are in the process of retiring the legacy scalb. IEEE-754 did not
specify what the argument types should be
* for scalb. We guessed scalb(double, int) -- ints are faster to use
here -- but our guess and what later standards
* standard eventually settled on did not agree. To be compliant with
these standards, our scalb needs to be scalb(double, double).
* Unfortunately, we have a commitment to be binary compatible with old
software compiled against scalb(double, int)
* for older operating systems, so the old symbol _scalb must live on in
perpetuity in the __ppc__ binary interface to service
* this need. To deal with this problem, we have introduced a new binary
symbol _scalb$UNIX2003 and did some magic below
* so that when you now compile against scalb() on a __ppc__
application, you get linked to _scalb$UNIX2003 instead. Thus,
* this constitutes a source level *** API CHANGE *** from scalb(
double, int ) to scalb( double, double) on __ppc__ only
* that your source will need to contend with if you compile with this
header. On __ppc__, all ints are exactly representable
* as doubles so from an arithmetic standpoint, this should cause no
changes arithmetically from parameters of int type, but there
* remains the danger of triggering various compiler warnings that might
balloon to more serious problems under -Werror.
*
* On __ppc64__, __i386__ and future archs, scalb has always been scalb(
double, double) and will continue to be so. Thus, this change
* will make scalb on all platforms behave identically, with the same
parameter types. The change will also eliminate GCC warnings about
* the math.h scalb declaration not matching the gcc4 builtin version.
*
* The intent is that you will "never know" that a change occurred, and
your code should "just do the right thing" without modification.
* However, if you would like to sidestep any problems associated with
this move, it is suggested that you use the C99 scalbn or scalbln
* or single/long double variants as appropriate instead. Their behavior
and type is rigorously defined. There should be no hidden arithmetic
* "gotchas" if you simply replace all legacy calls to scalb with
scalbn, since they essentially do the same thing. If you
* decide to take this step, you should exercise due diligence to make
sure that scalbn is present in the oldest version of
* MacOS X that you support. Otherwise, your application may fail to
load on older systems. C99 support was introduced in MacOS X.3.9.
*
* Use of the symbol _scalb$UNIX2003 should not in itself be construed
to mean that scalb$UNIX2003 necessarily is UNIX 2003 compliant.
* UNIX is a registered trademark of The Open Group.
*/
/* maps to _scalb$UNIX2003 on __ppc__ and _scalb elsewhere */
#if defined( __ppc__ )
extern double scalb ( double, double ) __asm("_scalb$UNIX2003" );
#else
extern double scalb ( double, double );
#endif
Howard Hinnant - 16 Aug 2006 23:04 GMT
> We still build our older toolkit with CW on PPC macs and recently
> upgraded to Xcode 2.4. When rebuilding the CW libraries and
[quoted text clipped - 14 lines]
> Anyone seen this? Have a fix? It would be nice if Apple kept stuff out
> of the standard headers that broke other compilers (obsolete or not).
Inspect your access paths preference panel. Ensure that the order of
your access paths is:
{Compiler}MSL/MSL_C
{OS X Volume}usr/include
and not vice-versa.
-Howard
dwhipps@mac.com - 21 Aug 2006 20:59 GMT
We've experienced this same error. Of course, you can avoid it by
building against the "10.4 SDK" but that doesn't help you if you want
to build against the system headers.
Also, I tried the fix about ordering the access paths and received the
discouraging but descriptive error:
"#error You must have the non-MSL C header file access path before the
MSL access path"
... in the "stddef.h" MSL header.
I tried building against the Mac OS X10.5 developer preview system
headers, and received similar errors.
Anyone know what we can do here?
- Dave
> > We still build our older toolkit with CW on PPC macs and recently
> > upgraded to Xcode 2.4. When rebuilding the CW libraries and
[quoted text clipped - 24 lines]
>
> -Howard
Howard Hinnant - 21 Aug 2006 21:03 GMT
> - Dave
>
[quoted text clipped - 26 lines]
> >
> > -Howard
> We've experienced this same error. Of course, you can avoid it by
> building against the "10.4 SDK" but that doesn't help you if you want
[quoted text clipped - 12 lines]
>
> Anyone know what we can do here?
Try putting:
#if !__option(precompile)
#include "MSLCarbonPrefix.h" /* was "Prefix file" */
#endif
in your preprocessing panel. This should be set up for you in Mach-O
stationary.
-Howard
Robert - 22 Aug 2006 19:37 GMT
Thank you for the replies, but just to make things perfectly clear, we
are rebuilding the system libraries and pre-compiled headers using the
BuildLibraries.mcp project. The error only comes in when rebuilding the
header files with MacHeadersMach-O.mcp project. We use the following
workflow after upgrading anything:
Open /Applications/Metrowerks CodeWarrior 9.0/Metrowerks CodeWarrior/
MSL/(MSL_Build_Projects)/BuildLibraries.mcp
Project->Remove Object Code
Recurse Subtarges and Subprojects: on
Project->Make
To make sure that the pre-compiled headers are done:
In the BuildLibraries project, double click:
Build.MacOSX.mcp->BuildMacOSXSupport.mcp->MacHeadersMach-O.mcp
for both targets, BSD MacHeadersMach-O and MSL MacHeadersMach-O
Project->Make
We do this last step since once it seemed that the pre-compiled heades
did not get re-built when running the normal library build.
On the other hand, the error doesn't stop the build and our own builds
(our code) seem to be fine.