hi, i think the best way to do that is compiling apr and apr-util before compiling httpd and remove your rpm openssl-devel ( rpm -qa | grep -i openssl and rpm -e openssl-devel...)
check this url http://httpd.apache.org/docs/2.4/en/install.html that could be helpfull -- Regard Jo Le 10 déc. 2012 à 21:27, John Iliffe <john.ili...@iliffe.ca> a écrit : > 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-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org >
