CODEWITHSUNDEEP
apachehttp
intechops6
intechops6

Reputation: 1097

Apache http 2.2.17 installation error - libexpat.so.0 not found

I am installing Apache 2.2.17 from source in Redhat 6.7 and seeing libexpat.so.0 not found. But I see the libexpat.so.0 available in /usr/lib64 and having /usr/lib64 path available in ld.so.conf file. After googling i found its a compatibility issue in the SO number libexpat.so.0 and libexpat.so.1. Reference:https://geekforum.wordpress.com/2014/06/17/install-apache-httpd-http-server/. I did removed the cache file following the above URL and ran ldconfig, but still seeing the error. I also did created the link libexpat.so.0 in /lib path to /usr/lib64/libexpat.so.0 but didn't work. Does anyone seen this issue in Redhat 6.7 and above. Is there any workaround for issues like this.
[root@servername ~]# ldd /local/installs/2.2.17/bin/httpd linux-gate.so.1 => (0x00627000) libm.so.6 => /lib/libm.so.6 (0x00477000) libaprutil-1.so.0 => /local/installs/2.2.17/lib/libaprutil-1.so.0 (0x002ec000) **libexpat.so.0 => not found** libapr-1.so.0 => /local/installs/2.2.17/lib/libapr-1.so.0 (0x00298000) librt.so.1 => /lib/librt.so.1 (0x00b61000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00182000) libpthread.so.0 => /lib/libpthread.so.0 (0x00a89000) libdl.so.2 => /lib/libdl.so.2 (0x0032d000) libc.so.6 => /lib/libc.so.6 (0x0086e000) /lib/ld-linux.so.2 (0x00ce8000) **libexpat.so.0 => not found** libfreebl3.so => /lib/libfreebl3.so (0x0024e000)

[edit] This issue is resolved.

Upvotes: 2

Views: 4186

Answers (1)

ahuemmer
ahuemmer

Reputation: 2047

When library problems like this one occur, I usually check the following points to make sure, everything is like it should:

  • Is the LD_LIBRARY_PATH correctly set to include all the folders containing libs? This has to be the case at compile time already. You would do it like this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64:/other/dir/with/libs ...
  • If the libraries exist but don't have the name expected (which should not occur on "clean" systems / good applications), you can create a link like this: ln -sf /path/to/existing/library.so /path/as/expected.so. Mostly you will only have to fiddle with the file version endings (.0, .1, etc.) Please be sure to link to the correct library and version.
  • Make sure, the libraries and these links have the correct access rights for the user trying to run the application depending on them

Also, check if you are accidentally mixing up 32 bit and 64 bit libs. As a rule of thumb, always use an application version matching your lib format and machine architecture (nowadays mostly 64bit). You cannot use a 32 bit application with 64 bit libs and vice versa. Also, using some libs as 32 bit and others as 64 bit won't work. Anyway, many 64 bit systems support running 32 bit applications by providing a second set of libs in 32 bit format ("multilib"), so you could try to run the 32 bit application if the 64 bit one fails or is not available.

Upvotes: 1

Related Questions