strange linking problems w/ apache with php including ldap support on solaris

strange linking problems w/ apache with php including ldap support on solaris

Post by Arnusch » Wed, 04 Sep 2002 21:18:46



Hi!

I'm trying to compile apache 1.3.26 with php 4.2.2 on Solaris 9 using
gcc 3.1.
I want to compile apache with ssl and php with ldap support.

First I install mm and openssl as base:

mm-1.2.1:
$./configure --prefix=/usr/iplanet/webgw --disable-shared
$make && make install

openssl-0.9.6e:
$./Configure --prefix=/usr/iplanet/webgw solaris-sparcv9-gcc
$make && make install

All went fine, so I continue installing the iplanet (former netscape)
ldap c sdk 5.1 (from the iplanet developer sites). The sdk is the same
as included in mozilla.

After this, I configure apache for the first time:
$cd apache_1.3.26
$./configure --prefix=/usr/iplanet/webgw

Then, I configure mod_ssl
$cd mod_ssl-2.8.10-1.3.26
$./configure --with-apache=../apache_1.3.26
--with-ssl=/usr/iplanet/webgw --with-mm=../mm-1.2.1
--enable-shared=ssl

after this, I configure and build php
$cd php-4.2.2
$./configure --with-apache=../apache_1.3.26 --enable-track-vars
--enable-inline-optimization --enable-memory-limit
--enable-magic-quotes --prefix=/usr/iplanet/webgw --with-gettext
--with-ldap=/usr/iplanet/webgw/ldap-sdk
$make && make install

The last part is installing configuring apache and build it:
$cd apache_1.3.26
./configure --prefix=/usr/iplanet/webgw --enable-module=so
--enable-module=ssl --activate-module=src/modules/php4/li
bphp4.a --enable-module=most --enable-shared=max
$make
$make certificate TYPE=test
$make install

All compilations went fine. When I try to start apache I'll get this
error:

$/usr/iplanet/webgw/bin/apachectl start
Syntax error on line 240 of /usr/iplanet/webgw/conf/httpd.conf:
Cannot load /usr/iplanet/webgw/libexec/libphp4.so into server:
ld.so.1: /usr/iplanet/webgw/bin/httpd: fatal: relocation error: file
/usr/iplanet/webgw/libexec/libphp4.so: symbol ldap_value_free_len:
referenced symbol not found
/usr/iplanet/webgw/bin/apachectl start: httpd could not be started

Ok, so the php modules cannot resolve a symbol. Why? The compilation
went fine, all symbols/includes have been found. It has nothing to do
with LD_LIBRARY_PATH etc (missing library), because when I do a

$ldd libphp4.so
        libpam.so.1 =>   /usr/lib/libpam.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libcrypt_i.so.1 =>       /usr/lib/libcrypt_i.so.1
        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
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libcmd.so.1 =>   /usr/lib/libcmd.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libthread.so.1 =>        /usr/lib/libthread.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
        /usr/platform/SUNW,Ultra-5_10/lib/libmd5_psr.so.1

you can see that php doesn't even try to look for the libldap.so! So
it doesn't load the library at all!

I have no clue why this happens. I'm really frustrated at the moment
because I tried to change the configure settings, version, compilers
etc.. It didn't change anything.
Is this some sort of strange linking bug in php?
I'm using gcc 3.1 or gcc 2.95.3 on Solaris 9 with the native binutils.

Thanks in advance
Arne Brutschy
--
CSK Software AG
Network Administration

Fax: +49-69-50952-299   Web  : http://www.csksoftware.com

 
 
 

strange linking problems w/ apache with php including ldap support on solaris

Post by Drazen Kaca » Thu, 05 Sep 2002 03:24:36



>  Ok, so the php modules cannot resolve a symbol. Why? The compilation
>  went fine, all symbols/includes have been found. It has nothing to do
>  with LD_LIBRARY_PATH etc (missing library), because when I do a

>  $ldd libphp4.so
>          libpam.so.1 =>   /usr/lib/libpam.so.1
>          libintl.so.1 =>  /usr/lib/libintl.so.1

You don't need to link in this file. That's not the cause of your problem,
though.

Quote:>          libcrypt_i.so.1 =>       /usr/lib/libcrypt_i.so.1
>          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
>          libpthread.so.1 =>       /usr/lib/libpthread.so.1
>          libc.so.1 =>     /usr/lib/libc.so.1
>          libcmd.so.1 =>   /usr/lib/libcmd.so.1
>          libgen.so.1 =>   /usr/lib/libgen.so.1
>          libmp.so.2 =>    /usr/lib/libmp.so.2
>          libthread.so.1 =>        /usr/lib/libthread.so.1
>          librt.so.1 =>    /usr/lib/librt.so.1
>          libaio.so.1 =>   /usr/lib/libaio.so.1
>          libmd5.so.1 =>   /usr/lib/libmd5.so.1
>          /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
>          /usr/platform/SUNW,Ultra-5_10/lib/libmd5_psr.so.1

>  you can see that php doesn't even try to look for the libldap.so! So
>  it doesn't load the library at all!

>  I have no clue why this happens.

When you are building an executable, by default the linker will complain
when it cannot satisfy all symbol references.

When you are building a shared object, by default the linker will not
comlain about such things. There are reasons for this, mostly having
something to do with history and developer ignorance[1].

In this particular case it would be benefitial to ask linker to complain
about unresolved symbols. You can do that by using -zdefs linker flag. I'm
not familiar with the PHP build process, so I don't know which
abominations you might encounter while trying to do that. If the build
process is correct, it will link the shared object with the compiler, so
you should be able to supply -Wl,-zdefs to the compiler's set of LDFLAGS.

If you manage to pass the flag, you're likely to get linker errors about
unresolved symbols. So you try to link again, this time supplying one or
more additional libraries which contain the needed symbols. When you
manage to do it without complains from -zdefs, you can be sure that your
shared object will not produce this kind of errors in run-time.

Quote:>  I'm really frustrated at the moment because I tried to change the
>  configure settings, version, compilers etc.. It didn't change anything.
>  Is this some sort of strange linking bug in php?

Most likely. Another thing to try with your existing shared object is:

   ldd -r libphp4.so

That should show all unsatisfied references. Those are the ones that
-zdefs would complain about.

[1] The proper technical term is "code monkeys".

--
 .-.   .-.    I don't work here. I'm a consultant.
(_  \ /  _)

     |

 
 
 

1. compiling PHP on Solaris with LDAP, but not SUN ldap

Hi,

trying to get PHP working with LDAP but to compile it the PHP doc says
must use Ldap libraries other than Sun's.  They mention specifically 3
types - University of Michigan  ldap-3.3 package,  Netscape Directory
SDK 3.0 or  OpenLDAP.

Does anyone know of Sun's are based enough on any of these for them to
work, and if not then would installing one of those mentioned mess up
anything on Solaris 9 since it seems to ship with it's own?

Thanks,

Tom

2. Adding I/O to a 486SX

3. re . apache ldap php solaris 8

4. Cola stats, last 7 days

5. Solaris - PHP- Apache- Oracle : Problem getting PHP installed

6. Linux - dual boot

7. PHP/Apache/LDAP Problem on AIX 4.3.2

8. input needed for a mini How-To on "multiple independent X sessions/ X users"

9. Problem with second included PHP file using Apache

10. Apache w/ PHP and SSL: w/ PHP OK - w/out PHP NOK

11. Strange problem with running php from within a cgi program in Apache 1.3

12. php and ldap and apache

13. Apache-PHP-Oracle linking problem