When you manage to get two different LDAP libraries loaded in the same process space, though, that probably means that there are other libraries in that space that "pulled in" the LDAP libraries. That's a problem because each of those libraries was compiled with information about the LDAP library it was linked against. Now one or the other has been rudely re-linked against a different LDAP library. If the LDAP libraries are very similar, and the libraries that use LDAP are doing simple, standard things, you may be okay. More likely, the library that ends up talking to a mismatched version of LDAP will display instability. That's where the error message in the title comes in.

../../../libraries/libldap/getentry.c:35: ldap_first_entry: Assertion ( (ld)->ld_options.ldo_valid == 0x2 )' failed.

That error comes from OpenLDAP, and is triggered when part of the OpenLDAP library's functions are overwritten with another library's functions - possibly a different version of OpenLDAP. Here are some possible scenarios in which it might come up:

You compile and install version A of OpenLDAP. You compile Apache with LDAP support (mod_ldap), linking it against OpenLDAP-A. Some time later, you install a second version of OpenLDAP, B. You then compile PHP, linking it against Apache and OpenLDAP-B. Now when you start Apache, the linker brings in shared libraries like this:

• Apache
  • mod_ldap
    • OpenLDAP-A
  • mod_php
    • OpenLDAP-B

Now if you use LDAP functions in PHP, you may get errors, crashes, or unexpected behavior, because PHP is calling OpenLDAP-A functions and expecting them to behave like OpenLDAP-B functions. Fortunately, in this case you can fix the problem by rebuilding PHP and/or Apache linked against the same version of OpenLDAP.

It's also possible to get this problem with staticly linked libraries. For example, again imagine you've built Apache linked against OpenLDAP. You then build mod_perl, linking it against Apache. It's important to note that unlike perl CGI, which runs as its own process distinct from Apache, mod_perl runs the perl interpreter within an Apache process - the two share a process space. Now you install the Oracle client and build the DBD::Oracle perl module linked against it. Finally, you run perl code from within mod_perl that calls DBD::Oracle and uses Oracle's LDAP functionality - calling OID, say. The partial list of linked-in libraries, both static and dynamic, looks like this:

• Apache
  • mod_ldap
    • OpenLDAP
  • mod_perl
    • DBD::Oracle
      • libclntsh.so (Oracle library)
        • Oracle LDAP library

The way out of this problem is less clear. It's not possible rebuild the Oracle libraries because they are closed-source. It may or may not be possible to rebuild Apache linked against the Oracle LDAP libraries - the Oracle client does come with include files, etc. but I haven't tried them. It's probably not desirable to have Apache linked against Oracle LDAP anyway. At the very least it prevents you using the Apache that comes with your distribution.

It may be possible to address the problem by adjusting the order in which the linker loads the LDAP libraries. In some cases program A may not work with library B, but program B works fine with library A. To alter the order that libraries are loaded, use the LD_PRELOAD environment variable. For example, to load the OpenLDAP libraries first when starting Apache:

LD_PRELOAD=/usr/lib64/libldap-2.3.so.0 /etc/init.d/httpd start

Or to load the Oracle client libraries first:

LD_PRELOAD=/usr/lib/oracle/10.2.0.3/client64/lib/libclntsh.so /etc/init.d/httpd start