I seem to remember having problems the last time I tried that. With gcc, you get relocation errors, missing symbols, all sorts of craziness. (I just checked with an extension compiled as a shared objected -- without extern c-ing php.h, I got an undefined symbol on zend_register_list_destructors.)
On Windows, I'm not even sure if VC++ would compile, but it's been a while since I checked. I'm pretty sure it had kittens over the non-extern-c-ed stuff. Fixing the API functions in php.h would definitely be the way to go, but I wasn't sure if I should go there, as I haven't had any problems yet with wrapping the whole thing up in extern C's. J Zeev Suraski wrote: > Why do we need an extern c before php.h? The relevant API functions in > php.h should be extern "c"d in my opinion, wrapping php.h up in extern "c" > is not very clean. > > Zeev > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
