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

Reply via email to