You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by John Iliffe <jo...@iliffe.ca> on 2012/12/10 02:18:22 UTC

[users@httpd] Compilation error in Apache 2.4.3

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


Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by John Iliffe <jo...@iliffe.ca>.
Thanks Tom.  I figured it was an OpenSSL problem; I've compiled Apache too 
often to expect an error there!  The OpenSSL documentation is somewhat 
sparse!  I completely missed the "shared" parameter in the configuration.

[as an aside on the OpenSSL documentation, for multi-threading, if the O/S 
supports it, then multi-threading is enabled by default; see the "Note on 
multi-threading" section.  The next paragraph is "Note on shared libraries" 
and it says: "the OpenSSL Configure script knows what is needed to
 build shared libraries for libcrypto and libssl.  On these systems,
 the shared libraries are currently not created by default, but giving
 the option "shared" will get them created. "    

I guess I stopped reading too soon!

Regards, and thanks,

John
==============================================
On Thursday 13 December 2012 12:35:45 Tom Evans wrote:
> On Mon, Dec 10, 2012 at 1:18 AM, John Iliffe <jo...@iliffe.ca> 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
> 
> The error is that the OpenSSL library you have built has not been
> built with PIC. Rebuild it with PIC so that it can be linked to a
> dynamically loaded module (mod_ssl.so).
> 
> The reason OpenSSL was not built with PIC is that you did not compile
> shared libraries for OpenSSL - you only created static libraries.
> OpenSSL compiles with PIC iff you enable shared libraries.
> 
> So, rebuild OpenSSL, this time passing '--enable-shared' to the
> configure script (or whatever the appropriate flag is).
> 
> Cheers
> 
> Tom
> 
> ---------------------------------------------------------------------
> 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


Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by John Iliffe <jo...@iliffe.ca>.
Thanks Allen.

Yes, I am using the source file from OpenSSL and not an RPM.  I suspect that 
the issue here is that I, or more correctly the make file, is trying to mix 
32 bit and 64 bit libraries.  I'll try being explicit about the library 
paths as suggested.

Haven't had any time to get back to it because I'm still dealing with other 
issues!

Regards,

John
=====================================
On Monday 14 January 2013 21:21:46 Allen Umlas wrote:
> You are trying to compile from the source file, sometime LD_LIBRARY PATH
> need to add manually pointing to where ssl located. try to manually add
> the path if not added.
> 
> try echo $LD_LIBRARY_PATH and check if LD_LIBRARY PATH exist on the
> path.
> 
> Is your openssl thru source file you compile or from rpm distribution?
> 
> 
> Regards,
> 
> Allen - Unix User
> 
> 
> ________________________________
>  From: John Iliffe <jo...@iliffe.ca>
> To: users@httpd.apache.org
> Sent: Monday, December 17, 2012 9:08 AM
> Subject: Re: [users@httpd] Compilation error in Apache 2.4.3
> 
> I have finally got back to this (why is building a new server always the
> lowest priority in the place?) and still have been unable to link in
> OpenSSL version 1.0.1c so it works.
> 
> I reconfigured and recompiled with --shared then made Apache with
> --with-ssl =/usr/openssl-1.0.1c but when I start Apache there are
> unresolved entry points in the SSL modules.  (SSL_.....  undefined
> symbol.)
> 
> This new server is a bit of a rush to get done before Christmas so I
> followed "Plan B" - there is always a Plan B in this business - and
> linked to the Red Hat distribution OpenSSL which did work (I think).  I
> will have to fix it later if anyone has any ideas due to PCI compliance
> issues but for the moment this allows the project to continue.
> 
> So, any ideas would be appreciated; programming isn't my first skill!
> 
> Regards,
> 
> John
> ================================================
> 
> On Thursday 13 December 2012 12:35:45 Tom Evans wrote:
> > On Mon, Dec 10, 2012 at 1:18 AM, John Iliffe <jo...@iliffe.ca> 
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
> > 
> > The error is that the OpenSSL library you have built has not been
> > built with PIC. Rebuild it with PIC so that it can be linked to a
> > dynamically loaded module (mod_ssl.so).
> > 
> > The reason OpenSSL was not built with PIC is that you did not compile
> > shared libraries for OpenSSL - you only created static libraries.
> > OpenSSL compiles with PIC iff you enable shared libraries.
> > 
> > So, rebuild OpenSSL, this time passing '--enable-shared' to the
> > configure script (or whatever the appropriate flag is).
> > 
> > Cheers
> > 
> > Tom
> > 
> > ---------------------------------------------------------------------
> > 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

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


Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by Allen Umlas <on...@yahoo.com>.

You are trying to compile from the source file, sometime LD_LIBRARY PATH need to add manually pointing to where ssl located. try to manually add the path if not added.

try echo $LD_LIBRARY_PATH and check if LD_LIBRARY PATH exist on the path.

Is your openssl thru source file you compile or from rpm distribution?


Regards,

Allen - Unix User


________________________________
 From: John Iliffe <jo...@iliffe.ca>
To: users@httpd.apache.org 
Sent: Monday, December 17, 2012 9:08 AM
Subject: Re: [users@httpd] Compilation error in Apache 2.4.3
 
I have finally got back to this (why is building a new server always the 
lowest priority in the place?) and still have been unable to link in 
OpenSSL version 1.0.1c so it works.

I reconfigured and recompiled with --shared then made Apache with --with-ssl 
=/usr/openssl-1.0.1c but when I start Apache there are unresolved entry 
points in the SSL modules.  (SSL_.....  undefined symbol.)

This new server is a bit of a rush to get done before Christmas so I 
followed "Plan B" - there is always a Plan B in this business - and linked 
to the Red Hat distribution OpenSSL which did work (I think).  I will have 
to fix it later if anyone has any ideas due to PCI compliance issues but for 
the moment this allows the project to continue.  

So, any ideas would be appreciated; programming isn't my first skill!

Regards,

John
================================================
On Thursday 13 December 2012 12:35:45 Tom Evans wrote:
> On Mon, Dec 10, 2012 at 1:18 AM, John Iliffe <jo...@iliffe.ca> 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
> 
> The error is that the OpenSSL library you have built has not been
> built with PIC. Rebuild it with PIC so that it can be linked to a
> dynamically loaded module (mod_ssl.so).
> 
> The reason OpenSSL was not built with PIC is that you did not compile
> shared libraries for OpenSSL - you only created static libraries.
> OpenSSL compiles with PIC iff you enable shared libraries.
> 
> So, rebuild OpenSSL, this time passing '--enable-shared' to the
> configure script (or whatever the appropriate flag is).
> 
> Cheers
> 
> Tom
> 
> ---------------------------------------------------------------------
> 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

Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by John Iliffe <jo...@iliffe.ca>.
I have finally got back to this (why is building a new server always the 
lowest priority in the place?) and still have been unable to link in 
OpenSSL version 1.0.1c so it works.

I reconfigured and recompiled with --shared then made Apache with --with-ssl 
=/usr/openssl-1.0.1c but when I start Apache there are unresolved entry 
points in the SSL modules.  (SSL_.....  undefined symbol.)

This new server is a bit of a rush to get done before Christmas so I 
followed "Plan B" - there is always a Plan B in this business - and linked 
to the Red Hat distribution OpenSSL which did work (I think).  I will have 
to fix it later if anyone has any ideas due to PCI compliance issues but for 
the moment this allows the project to continue.  

So, any ideas would be appreciated; programming isn't my first skill!

Regards,

John
================================================
On Thursday 13 December 2012 12:35:45 Tom Evans wrote:
> On Mon, Dec 10, 2012 at 1:18 AM, John Iliffe <jo...@iliffe.ca> 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
> 
> The error is that the OpenSSL library you have built has not been
> built with PIC. Rebuild it with PIC so that it can be linked to a
> dynamically loaded module (mod_ssl.so).
> 
> The reason OpenSSL was not built with PIC is that you did not compile
> shared libraries for OpenSSL - you only created static libraries.
> OpenSSL compiles with PIC iff you enable shared libraries.
> 
> So, rebuild OpenSSL, this time passing '--enable-shared' to the
> configure script (or whatever the appropriate flag is).
> 
> Cheers
> 
> Tom
> 
> ---------------------------------------------------------------------
> 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


Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by Tom Evans <te...@googlemail.com>.
On Mon, Dec 10, 2012 at 1:18 AM, John Iliffe <jo...@iliffe.ca> 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

The error is that the OpenSSL library you have built has not been
built with PIC. Rebuild it with PIC so that it can be linked to a
dynamically loaded module (mod_ssl.so).

The reason OpenSSL was not built with PIC is that you did not compile
shared libraries for OpenSSL - you only created static libraries.
OpenSSL compiles with PIC iff you enable shared libraries.

So, rebuild OpenSSL, this time passing '--enable-shared' to the
configure script (or whatever the appropriate flag is).

Cheers

Tom

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


Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by Bouchot Jonathan <bo...@gmail.com>.
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 <jo...@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-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
> 

Re: [users@httpd] Compilation error in Apache 2.4.3

Posted by John Iliffe <jo...@iliffe.ca>.
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