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
|