httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Iliffe <john.ili...@iliffe.ca>
Subject Re: [users@httpd] Compilation error in Apache 2.4.3
Date Mon, 10 Dec 2012 20:27:25 GMT
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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message