Re: Problem with PHP as a plugin (C++) using embed sapi

Hi, On Fri, 2011-10-14 at 10:49 +0200, Olivier Hoareau wrote: > * My use case : > > [A] is a main program written in C++ > [B] is a C++ "plugin" of [A], compiled in a shared library dynamically loaded > (dlopen-like functions) > [CX] are a libphpX.so C shared libraries compiled with "--enable-embed", where > "X" is the PHP version number (5.4, 5.3, ..., 5.0) > Do you have an idea on how to reach my use case ? The simple answer is: You can't do this this way and you have to provide a [B] for each version of PHP linking [CX]. If you really really really want to do this I see two ways, where the first is close to what you are doing but still evil: The approach is to add a Loader library which is loaded by [A] and then first loads [CX] and then the current [B]. This is evil as PHP does not guarantee API/ABI to stay the same over minor versions. So some random function in libphp, which your [B] might be using, can change the signature which will easily lead to hard to debug crashes of your application. The better approach is to create your own SAPI which exports a for your purpose stable API which you then can load. Building a SAPI is not really hard. https://github.com/johannes/pconn-sapi/blob/master/pconnect-sapi.c is probably one of the most simple SAPIs, there I'm basically exporting three more abstracted functions: pconn_init_php(), pconn_shutdown_php() and pconn_do_request() which in your case would form your stable API for your new SAPI. (mind that my pconn_do_request() includes a TSRM parameter, in case you don't need threaded execution, can be dropped, else you probably have to abstracted it away (make it void* and export clean APIs to keep thread context), too) johannes