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
that could be helpfull
--Regard Jo 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-aprIt 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@xxxxxxxxxxxxxxxxFor additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|
