Reputation: 691
We are trying to create a PHP extension in C++ that will operate as a CORBA client.
The server side is written in Java. Our runtime environment is CentOS 6.6.
We have used omniORB to compile the IDL and create the C++ skeleton code for the client. Our first step was to create a client program that works correctly. We then included the functionality in a PHP extension that compiles and links without any errors.
When however our extension library is installed and tested in PHP we get the following error:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/php_midas.so' - /usr/lib64/php/modules/php_midas.so: undefined symbol: _ZTv0ortableServer11ServantBase9_downcastEv in Unknown on line 0.
Upvotes: 3
Views: 406
Reputation: 691
The solution to the problem was to change the config.m4 file used for setting up the php extension, so that it included references to the omniORB libraries using the PHP_ADD_LIBRARY_WITH_PATH
macro instead of the PHP_ADD_LIBRARY
one, although the libraries were in the default /usr/lib64 folder.
I am including the entire file as a working reference.
dnl PHP extension definition written in C++ that uses the omniORB libraries
PHP_ARG_ENABLE(php_midas, whether to enable midas extension, [ --enable-php-midas Enable PHP Midas extension])
if test "$PHP_MIDAS" != "no"; then
dnl -- Add support for standard C++ runtime
PHP_ADD_LIBRARY_WITH_PATH( stdc++, /usr/lib64/, PHP_MIDAS_SHARED_LIBADD)
dnl -- Incldue the omniORB libraries
PHP_ADD_LIBRARY_WITH_PATH(omniCodeSets4, /usr/lib64/, PHP_MIDAS_SHARED_LIBADD)
PHP_ADD_LIBRARY_WITH_PATH(omniConnectionMgmt4, /usr/lib64/, PHP_MIDAS_SHARED_LIBADD)
PHP_ADD_LIBRARY_WITH_PATH(omniDynamic4, /usr/lib64/, PHP_MIDAS_SHARED_LIBADD)
PHP_ADD_LIBRARY_WITH_PATH(omniORB4, /usr/lib64/, PHP_MIDAS_SHARED_LIBADD)
PHP_ADD_LIBRARY_WITH_PATH(omnithread, /usr/lib64/, PHP_MIDAS_SHARED_LIBADD)
dnl -- Our extension consists of two cpp files
PHP_NEW_EXTENSION(php_midas, php_midas.cpp coordinatesConverterSK.cpp, $ext_shared)
PHP_SUBST(PHP_MIDAS_SHARED_LIBADD)
dnl -- Declare C++ extension
PHP_REQUIRE_CXX()
fi
Upvotes: 1
Reputation: 1865
Altered from Source:
There are many different reasons which could cause such a problem with the DLLs. First - Ensure all the files are in place - does the midas module exist there? is there a proper referance to it in the enviroment?
Make sure the extension is set -Make sure you have the SO module, and then that your configuration file has the SO type as the extension type, or in other words, this line exists:
extension=module.so
If this didn't help, consider dynamically checking the linker - is the error in the loading, or some of the headers didnt fit?
Let me know what happened.
EDIT: It seems like the error is in the loading beacuse of undefined syntax. Well then, here is a similar case I will base my answer on.
Your error means, that ZTv0ortableServer11ServantBase9_downcastEv
symbol cannot be found in shared libraries used by the module. It is probably provided by a library which is not a defualt - not php-gd, probably omniORB.
readelf -s <path to SO file>
and
nm -D <path to SO file>
will list symbols and I'm very sure, that you won't find it there.
There's probably an unupdated library from the omniORB type interfering with the referance - for example Remi could be one. If you have it in your code, or any other one which might do this, you could reset them;
For example, if you think the remi files are interfering, you can reset them by Removing all remi packages (rpm -qa|grep remi
), delete remi-release package and install last available php/gg/etc packages from EPEL repository (you may need to downgrade them with rpm -Uvh package.rpm --oldversion
). Then upgrade all packages.
Some more links with similar questions can be found here, here, here, and even here.
Let me know if this helped you.
Upvotes: 0