I have the task to build a couple of Apache Web servers on a some Dell servers running RHEL5. One version of RHEL5 is 32-bit, the other 64-bit. The 32-bit box compiles and runs Apache and Tomcat fine, but the 64-bit box does not. Here is the configure line:

./configure CFLAGS="-DWITH_THREADS -fPIC" CPPFLAGS="-DWITH_THREADS -fPIC" --prefix=/usr/local/apache2 --with-perl=/usr/bin/perl5.8.8 --enable-so --with-mpm=prefork --with-port=80 --with-expat=/usr/local --with-z=/usr/local/src/zlib-1.2.3 --enable-deflate --with-ssl=/usr/local/src/openssl-0.9.8k --enable-mods-shared="all cgid deflate ext_filter jk ssl"

When I run the same configure command on either box, all is well. make runs error-free on the 32-bit box, but I receive this error on the 64-bit box:

<snip>
Building shared: mod_ssl.la
make[4]: Entering directory `/usr/local/src/httpd-2.0.63/modules/ssl'
/usr/local/src/httpd-2.0.63/srclib/apr/libtool --silent --mode=link gcc -pthread -DWITH_THREADS -fPIC -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -DWITH_THREADS -fPIC -I/usr/local/src/httpd-2.0.63/srclib/apr/include -I/usr/local/src/httpd-2.0.63/srclib/apr-util/include -I/usr/local/include -I. -I/usr/local/src/httpd-2.0.63/os/unix -I/usr/local/src/httpd-2.0.63/server/mpm/prefork -I/usr/local/src/httpd-2.0.63/modules/http -I/usr/local/src/httpd-2.0.63/modules/filters -I/usr/local/src/httpd-2.0.63/modules/proxy -I/usr/local/src/httpd-2.0.63/include -I/usr/local/src/httpd-2.0.63/modules/generators -I/usr/local/src/zlib-1.2.3/include -I/usr/local/src/httpd-2.0.63/server -I/usr/local/src/openssl-0.9.8k/include/openssl -I/usr/local/src/openssl-0.9.8k/include -I/usr/kerberos/include -I/usr/local/src/httpd-2.0.63/modules/dav/main -export-dynamic -L/usr/local/lib -L/usr/local/src/zlib-1.2.3/lib -L/usr/local/ssl/lib -o mod_ssl.la -rpath /usr/local/apache2/modules -module -avoid-version mod_ssl.lo ssl_engine_config.lo ssl_engine_dh.lo ssl_engine_init.lo ssl_engine_io.lo ssl_engine_kernel.lo ssl_engine_log.lo ssl_engine_mutex.lo ssl_engine_pphrase.lo ssl_engine_rand.lo ssl_engine_vars.lo ssl_expr.lo ssl_expr_eval.lo ssl_expr_parse.lo ssl_expr_scan.lo ssl_scache.lo ssl_scache_dbm.lo ssl_scache_shmcb.lo ssl_scache_shmht.lo ssl_util.lo ssl_util_ssl.lo ssl_util_table.lo -L/usr/kerberos/lib64 -lssl -lcrypto -ldl -lz
/usr/bin/ld: /usr/local/ssl/lib/libssl.a(s2_srvr.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/ssl/lib/libssl.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [mod_ssl.la] Error 1
make[4]: Leaving directory `/usr/local/src/httpd-2.0.63/modules/ssl'
make[3]: *** [shared-build-recursive] Error 1
make[3]: Leaving directory `/usr/local/src/httpd-2.0.63/modules/ssl'
make[2]: *** [shared-build-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/httpd-2.0.63/modules'
make[1]: *** [shared-build-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/httpd-2.0.63'
make: *** [all-recursive] Error 1
[root@httpd-2.0.63]#

Any ideas? Thanks in advance.

The important part of the output you quoted was:

I've seen that error message many times when it is correct. So you would need to add -fPIC to the compile command and clean and rebuild libssl.a. Typically, there is a CFLAGS or similar environment variable that is input to the build process.

I've also see that error message when something else is wrong.

I forget what libssl is, so I'm not sure, but there may be better alternatives to rebuilding the .a, for example can you get a .so for that?

Edit: I checked the availability of libssl.a and libssl.so using yum provides in Centos 5.3. Both are available and both would be installed in /usr/lib64 if you installed the right package.

I'm not certain, but I think the fact those are available in Centos 5.3 should mean they are available in RHEL 5.

Your failure occurred after finding libssl.a in /usr/local/ssl/lib

1) I think the command you used would have used libssl.so if it had found that and only used libssl.a because it didn't find libssl.so

2) The error message indicates that libssl.a was compiled in a way that allows it to be used only when linking into main executables and not when linking into .so files (which it thinks it is doing). I don't know if that should be considered a problem with the way libssl.a was compiled or whether you are always supposed to use libssl.so (which couldn't have this problem) in this situation.

3) Why do you have libssl.a in /usr/local/ssl/lib instead of in /usr/lib64 ?
I assume that means you installed libssl by some means other than the supported rpm, either instead of or in addition to the supported rpm. If you had a good reason for installing a non standard libssl, I think you still may have done so incorrectly. If you didn't have a good reason for installing a non standard libssl, I think you ought to get rid of it and install the standard package.