Re: [Plib-users] Re: link plib into code on mac osx

[Bernhard W. <bw...@ca...>]

On 29 Oct 2004, at 14:14, Steve Baker wrote:
> I think there is something stranger than this going on. Probably,
> the compiler puts an automatic 'extern "C" { ... }' around header
> files that it thinks are lacking that for some reason beyond the
> compiler writer's control - but gcc/g++ doesn't do this for
> Windows or Linux - so why would it do that for the Mac?
>
> I think we need to understand what's going on a bit better before
> we start installing PLIB in non-standard (for PLIB) places because
> if Mac users start relying on the headers being in some bizarre
> location, they'll write code that's not portable to other OS's
> and other OS's code won't work for them - and that's not acceptable.

Fair enough! And I am definitely not specialist enough to see even the 
simple consequences.

Nevertheless, all C++-headers in OS X (so all the standard C++ 
replacements for C libraries like "cstdlib", "cstdarg", "cmath" of for 
example all the stream-headers like "iostream", "fstream" and 
"sstream") are to be found in the path /usr/include/gcc/darwin/3.3/c++ 
anyway. So it wouldn't really be a bizarre location for other C++ 
headers to be in.

One more thing that I found though. In the tar-package of plib, the 
symbols "puSetColor" and "puSetColour" in "pu.h" are defined as inline 
as can be checked in the /src directory of the untared library. For 
some strange reason, the "pu.h" that is installed in the /usr/include 
directory is missing the "inline" keyword in front of these symbols. 
That causes severe problems when the header "pu.h" is included in more 
than one module in the project. I am not sure why the /usr/include file 
is missing this keyword but the error can be mended by simply putting 
"inline" in front of the symbols declaration as it was in the /src 
file.

Bernhard