Just for clarification, I now know that the config line was wrong; I didn't see the note about having to use "with-included-apr" when moving the apr files to the srclib directory. I retried with the following: ./configure --prefix=/usr/apache-2.4.3 --with-ssl=/usr/openssl-1.0.1c --with- zlib --with-pcre=/usr/pcre-8.32 --with-included-apr It still crashes during the make phase with the same messages. Regards, John ============================================ On Sunday 09 December 2012 20:18:22 John Iliffe wrote: > I am trying to install Apache 2.4.3 on a new Red Hat Linux 6.3 machine > running on X86_64 hardware. > > I installed OpenSSL version 1.0.1c and it seemed to install correctly. > basically, it was a default install except for the executable location > information. > > ------------------------------------------------------------------------ > ----- ./configure --prefix=/usr/openssl-1.0.1c > make > make install > ------------------------------------------------------------------------ > ---- I ran a few tests from the command line and the results look OK. > > When I try to compile Apache using the following configuration, I get a > compile error against the OpenSSL libraries: > > ------------------------------------------------------------------------ > ------------------ ./configure --prefix=/usr/apache-2.4.3 > --with-ssl=/usr/openssl-1.0.1c --with- zlib --with-pcre=/usr/pcre-8.32 > ------------------------------------------------------------------------ > ------------------ > > Note that the path to OpenSSL is required in the --with-ssl parameter > because I don't want to link to the included RedHat OpenSSL version due > to PCI requirements. (too old) > > This runs for a while and then I get the following fatal error: > > ------------------------------------------------------------------------ > ------------------- /usr/bin/ld: > /usr/openssl-1.0.1c/lib/libssl.a(s3_srvr.o): relocation R_X86_64_32 > against `.rodata' can not be used when making a shared object; > recompile with -fPIC > /usr/openssl-1.0.1c/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 `/tmp/httpd-2.4.3/modules/ssl' > make[3]: *** [shared-build-recursive] Error 1 > make[3]: Leaving directory `/tmp/httpd-2.4.3/modules/ssl' > make[2]: *** [shared-build-recursive] Error 1 > make[2]: Leaving directory `/tmp/httpd-2.4.3/modules' > make[1]: *** [shared-build-recursive] Error 1 > make[1]: Leaving directory `/tmp/httpd-2.4.3' > make: *** [all-recursive] Error 1 > ------------------------------------------------------------------------ > ------- > > I looked up fPIC in the GCC documentation and it says: > > ------------------------------------------------------------------------ > --- -fPIC > If supported for the target machine, emit > position-independent code, suitable for dynamic linking and > avoiding any limit on the size of the global offset table. > This option makes a difference on the m68k, > PowerPC and SPARC. > > Position-independent code requires special support, and > therefore works only on certain machines. > > When this flag is set, the macros "__pic__" and "__PIC__" are > defined to 2. > > ------------------------------------------------------------------------ > ------ > > Since I'm not running one of the class of machine that fPIC addresses I > checked what GCC is worrying about and find: > > ------------------------------------------------------------------------ > -------- -fpic > Generate position-independent code (PIC) suitable for use in > a shared library, if supported for the > target machine. Such code accesses all constant addresses > through a global offset table (GOT). The > dynamic loader resolves the GOT entries when the program > starts (the dynamic loader is not part of GCC; > it is part of the operating system). If the GOT size for the > linked executable exceeds a machine- > specific maximum size, you get an error message from the > linker indicating that -fpic does not work; in > that case, recompile with -fPIC instead. (These maximums are > 8k on the SPARC and 32k on the m68k and > RS/6000. The 386 has no such limit.) > > Position-independent code requires special support, and > therefore works only on certain machines. For > the 386, GCC supports PIC for System V but not for the Sun > 386i. Code generated for the IBM RS/6000 is > always position-independent. > > When this flag is set, the macros "__pic__" and "__PIC__" are > defined to 1. > ------------------------------------------------------------------------ > ------------------- > > This doesn't make a lot of sense as I don't believe that the relocation > table can have overflowed on a 8 Gb memory machine running nothing else > but the compiler at the moment! > > What I **think** happened is that I am trying to link 32 bit code to 64 > bit code but I have no idea how to fix that. Always assuming that I > read the instructions right :-( > > Does anyone know how to approach debugging this? > > Regards, > > John > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|