PHP extension CORBA client with omniORB libraries gives runtime error with "undefined symbol "

Question

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.

Answer 1

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

Answer 2

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.