On Mon, 5 Feb 2007 15:42:49 -0500 James Carlson wrote: > Glenn Fowler writes: > That's exactly my question: rather than saying vaguely that it > "screws-up" the compilation, what actual problems are seen?
sorry, I don't like "x doesn't work", with no further info, either Roland, can you dig up the original msg for this problem? > Is AST walking into areas where it shouldn't be defining symbols? Are > we just seeing the tip of an iceberg here? > The issue is bigger than just the _LP64 symbol. I'm quite puzzled > that there could be a reasonable, portable application out there that > would be blown away by <stddef.h>. Something about that just doesn't > ring true to me. the ast build compensates for the gamut of standards (real, de-facto, and vendor-specific) and if the headers and/or feature test macros seen at the front end of the build change towards the back end, then "ast stepping on the std namespace" may be intentional, but just fouled up by different parts of the build running with different feature test macros and/or headers e.g., if a native system does not supply strcasecmp(), then ast will supply one via its headers+lib; if subsequently a feature test macro is defined that enables the native strcasecmp() then a clash with strcasecmp() could arise compiling against the ast headers/lib as I recall, some errors like this arose from coaxing the solaris build to make the latest iso C math functions visible to ksh93 -- moving that coaxing from ksh93 to the ast libs eliminated the conflicts -- Glenn Fowler -- AT&T Research, Florham Park NJ -- _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
