FIX: undefined symbol: apr_ldap_ssl_init

Did an update to Ubuntu Jaunty and Apache stopped working with the message “undefined symbol: apr_ldap_ssl_init”. This post is how I fixed it.

This is a geek entry for resolving the problem:

* Restarting web server apache2
/usr/sbin/apache2: symbol lookup error: /usr/sbin/apache2: undefined symbol: apr_ldap_ssl_init [fail]

Non-geeks will want to move along…

After a standard apt-get update, apt-get upgrade on Ubuntu 9.04 Jaunty, I was unable to start apache (httpd) due to an undefined symbol.

Suggested fixes of repairing broken symbolic links in /usr/lib, reinstalling the apr library, and twiddling Apache’s ldap modules didn’t work.

The fix came from inspiration left by Rhys Ulerich, who left a comment, saying:

I also ran into this problem, but the root cause was that I’d built the Apache Portable Runtime in /usr/local for some other development work, completely forgot about it, and apache2 was picking up libraries from /usr/local/lib before /usr/lib.

Indeed this was the problem.

Ubuntu, while my current favorite choice as best-Linux-distribution-ever, has the horrible problem of suffering from severe lag of keeping up to date with the latest Subversion. Why this is so, I don’t know, but it’s forced us to have to build subversion manually — an easy enough task, but I’d really rather use an up-to-date repository.

Part of subversion’s build process is to build the APR library, although it’s better to simply use subversion-deps.

Through a set of manual builds and system updates, I ended up with a build in /usr/local/apr/lib and a build in /usr/lib.

By going to /etc/ld.so.conf.d, and doing grep apr *, I was able to find that I had a manually created file called usr-local.conf that contained /usr/local/apr/lib and /usr/local/BerkeleyDB.4.7/lib in it.

Deleting the /usr/local/apr/lib line, and then running # ldconfig, which altered the shared libraries loaded by the synamic linker run-time bindings, this solved the problem.

Apache2 was now looking at /usr/lib, and it found the apr library it wanted.

0 thoughts on “FIX: undefined symbol: apr_ldap_ssl_init”

  1. That’s one cause.

    I had a similar cause, but with a different resolution. I ended up having a newer version of libapr1 and libaprutil1 installed locally than the repository had (repo was version libaprutil-1.so.0.3.9, yet I had version libaprutil-1.so.0.3.10 installed locally).

    The issue was that the re-installation of the older package would not update the links to the repo install, since it was a “newer” version – but one that didn’t have the proper symbols in it.

    This was likely due to my attempts to get Subversion 1.7.x working, since I needed some of the newer features and the repo (as you note) lags seriously when it comes to subversion.

    The fix (for me):

    # apt-get purge libapr1 libaprutil1 apache2

    # rm /usr/lib/libapr*
    # rm /usr/lib/apr.exp
    # rm /usr/lib/aprutil.exp
    # rm -r /usr/lib/apr-util-1

    # apt-get install apache2

  2. Thank you very much.
    I have tried everything mentioned (repairing broken symbolic links in /usr/lib, reinstalling the apr library, and twiddling Apache’s ldap modules ) in the post prior to coming to this page.
    It took me a little bit time before I could follow the process (I am very new in this area)
    But I am saved!

    Changing the path for the library, this is how it worked for me:

    root@desktop:/etc/ld.so.conf.d# vim libc.conf
    root@desktop:/etc/ld.so.conf.d# ldconfig
    root@desktop:/etc/ld.so.conf.d# /etc/init.d/apache2 restart
    * Restarting web server apache2 apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
    apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
    [ OK ]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.