php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34904 Relocation error in libphp5.so when starting Apache2
Submitted: 2005-10-18 11:03 UTC Modified: 2005-11-01 18:51 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: sean dot healey at bayernlb dot co dot uk Assigned:
Status: Not a bug Package: Sybase-ct (ctlib) related
PHP Version: 5.0.5 OS: Solaris 8
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sean dot healey at bayernlb dot co dot uk
New email:
PHP Version: OS:

 

 [2005-10-18 11:03 UTC] sean dot healey at bayernlb dot co dot uk
Description:
------------
I am getting the following error when trying
to start Apache2 with the PHP plugin configured:

# ./apachectl start
Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1:
/usr/local/apache2/bin/httpd: fatal: relocation error: file
/dpkg/sybase/OCS-12_0/lib/libtcl.so: symbol comn_free: referenced symbol not
found


When built without Sybase client library, the plugin starts up just fine. The php module DOES appear to be linked against the correct copy of libtcl.so - here are the without-sybase and with-sybase ldd outputs:

# ldd libphp5.so.without_sybase
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.1 =>     /usr/lib/libm.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libz.so.1 =>     /usr/lib/libz.so.1
        libxml2.so.2 =>  /usr/local/lib/libxml2.so.2
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1


# ldd libphp5.so
        libtcl.so =>     /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libcomn.so =>    /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so
        libct.so =>      /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so
        libcs.so =>      /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.1 =>     /usr/lib/libm.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libz.so.1 =>     /usr/lib/libz.so.1
        libxml2.so.2 =>  /usr/local/lib/libxml2.so.2
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1


I have noticed that libintl.so.1 should be picked up from the Sybase client libs directory, but is linking from the system libs directory instead. Can't tell if this is related.

I have tried this build both against client library vers 12.0 and 12.5 with identical results. Have noted similar bugs reported for previous versions of PHP.

Setting LD_LIBRARY_PATH in the Apachectl script does not fix the problem.

Reproduce code:
---------------
#!/usr/bin/sh

DSQUERY=fx_dbserver2_ds
SYBASE=/dpkg/sybase/sybase12_5
SYBASE_OCS=OCS-12_5
LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH

PATH=$SYBASE/$SYBASE_OCS/bin:/usr/ccs/bin:/usr/local/bin:/usr/sbin:/usr/bin

CPPFLAGS="-I$SYBASE/$SYBASE_OCS/include:/usr/local/include:/usr/include:/usr
/dt/include:/usr/openwin/include:/usr/local/include/libxml2/libxml:/usr/loca
l/include/libxml2/libxslt:/usr/local/include/libpng:/usr/local/BerkeleyDB.4.
2/include"

LDFLAGS="-L$SYBASE/$SYBASE_OCS/lib:/usr/ccs/lib:/usr/local/lib:/usr/lib:/usr
/dt/lib:/usr/openwin/lib:/usr/local/BerkeleyDB.4.2/lib:
-R$SYBASE/$SYBASE_OCS/lib:/usr/ccs/lib:/usr/local/lib:/usr/lib:/usr/dt/lib:/
usr/openwin/lib:/usr/local/BerkeleyDB.4.2/lib"

export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH CPPFLAGS LDFLAGS

cd php-5.0.5


./configure \
  --prefix=/usr/local/php \
  --with-apxs2=/usr/local/apache2/bin/apxs \
  --with-sybase-ct=$SYBASE/$SYBASE_OCS \
  --without-bz2 \
  --enable-sysvmsg \
  --enable-sysvsem \
  --enable-sysvshm



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-26 17:43 UTC] sniper@php.net
Don't try outsmarting the configure. User error -> not PHP bug.
 [2005-10-27 11:30 UTC] sean dot healey at bayernlb dot co dot uk
Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths.

It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead.

I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results.

My original configure script is:

#!/usr/bin/sh

DSQUERY=fx_dbserver2_ds
SYBASE=/dpkg/sybase/sybase12_5
SYBASE_OCS=OCS-12_5
LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH
PATH=/usr/ccs/bin:$PATH

export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH

cd php-5.0.5

./configure \
  --prefix=/usr/local/php \
  --with-apxs2=/usr/local/apache2/bin/apxs \
  --with-sybase-ct=$SYBASE/$SYBASE_OCS \
  --without-bz2

This produces a libphp5.so which is linked as follows:

ldd /usr/local/apache2/modules/libphp5.so
        libtcl.so =>     /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libcomn.so =>    /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so
        libct.so =>      /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so
        libcs.so =>      /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.1 =>     /usr/lib/libm.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libz.so.1 =>     /usr/lib/libz.so.1
        libxml2.so.2 =>  /usr/local/lib/libxml2.so.2
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1


NOTE that the reference to libintl is still linked to the wrong library.

I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library.

A solved case on the Sybase site mentions that the Solaris library /usr/lib/libintl.so.1 has nothing to do with the Sybase library of the same name, which is possibly why the object not found error since my build is linking to the wrong library!
 [2005-10-27 18:18 UTC] sean dot healey at bayernlb dot co dot uk
I have managed to get around the build problem by sym-linking libintl.so -> libintl.so.1 in the Sybase libraries path. Apache2 now starts with the php5 module configured.

This seems to me to be an issue with the PHP build - we have no such problems compiling other CTLIB applications!

Please note - the 'duplicate' name of the libintl library is NOT Sybase's problem. Sybase support say that they created that library 'years' before Solaris introduced one of the same name.

Bittersweet victory though, because now sybase_connect() won't connect despite the interfaces file being present, correct and configured in php.ini.
 [2005-10-27 18:46 UTC] sean dot healey at bayernlb dot co dot uk
Just another thing to note: The following message appears during 'make install' ...

"libtool: install: warning: remember to run `libtool --finish /var/build/php-5.0.5/libs'"

I would expect to see the message ...

----------------------------------------------------------------------
Libraries have been installed in:
   /var/build/php-5.0.5/libs

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - use the `-RLIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

... during the install phase, but this is missing. I presume this is purely informational?

Sorry - I know this is unrelated to the above, just thought I should bring it to your attention.
 [2005-11-01 11:24 UTC] sniper@php.net
This still isn't PHP bug.

 [2005-11-01 18:51 UTC] sean dot healey at bayernlb dot co dot uk
No, perhaps not a bug with PHP itself, but definitely an issue with the build process!!

You telling me you're just going to leave Solaris users who need Sybase support swinging in the breeze?

I strongly suspect the problem is to do with GCC - which uses the non-Sybase version of the libintl library, but haven't had time to investigate further.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Jun 19 00:01:28 2019 UTC