Clever Geek Handbook

CORBA PHP client extension with omniORB libraries gives runtime error with undefined character

We are trying to create a PHP C ++ extension that will work as a CORBA client.

The server side is written in Java. Our runtime is CentOS 6.6.

We used omniORB to compile IDL and generate C ++ skeleton code for the client. Our first step was to create a client program that works correctly. We then incorporated the functionality into a PHP extension that compiles and links without any error.

If 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.

+3


source to share


2 answers


The solution to the problem was to change the config.m4 file used to configure the php extension to include references to omniORB libraries using a macro PHP_ADD_LIBRARY_WITH_PATH

instead PHP_ADD_LIBRARY

, even though the libraries were in the default / usr / lib 64 folder.

I am including the entire file as a working link.



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
+1


source


Modified from Source:

There are many different reasons that can cause this DLL problem. First - Make sure all files are in place - does the midas module exist? is there an appropriate attitude towards it in the environment?

Make sure the extension is installed . Make sure you have an SO module and then your config file is of type SO as extension type, or in other words, this line exists:

extension=module.so

If that doesn't work, consider dynamically checking the linker - is this a loading error, or are some of the headers not appropriate?

Let me know what happened.

EDIT . It looks like the error is related to loading undefined syntax. So here is a similar case for which I will describe my answer.

Your error means that the symbol ZTv0ortableServer11ServantBase9_downcastEv

cannot be found in the shared libraries used by the module. This is probably provided by a library that is not defualt - not php-gd, possibly omniORB.



readelf -s <path to SO file>

and

nm -D <path to SO file>

will display symbols and I'm sure you won't find it there.

Probably an invalid omniORB library interfering with the link, for example Remi can be one. If you have these in your code, or anyone else that could do it, you could reset them;

For example, if you think remi files are getting in the way, you can reset them with all remi packages ( rpm -qa|grep remi

), remove the remi-release package, and install the latest available php / gg / etc packages from the EPEL repository (you may need to downgrade them from help rpm -Uvh package.rpm --oldversion

). Then update all packages.

Several links with similar questions can be found here, here , here , and even here.

Let me know if this helped you.

0


source






More articles:


All Articles