Return-Path: X-Original-To: apmail-httpd-users-archive@www.apache.org Delivered-To: apmail-httpd-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3A3B2D6E0 for ; Mon, 10 Dec 2012 20:27:57 +0000 (UTC) Received: (qmail 88978 invoked by uid 500); 10 Dec 2012 20:27:54 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 88957 invoked by uid 500); 10 Dec 2012 20:27:54 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 88949 invoked by uid 99); 10 Dec 2012 20:27:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2012 20:27:53 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of john.iliffe@iliffe.ca designates 206.248.138.118 as permitted sender) Received: from [206.248.138.118] (HELO iliffe.ca) (206.248.138.118) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2012 20:27:48 +0000 X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=192.168.1.10; Received: from wkstn01.iliffe.ca (unverified [192.168.1.10]) by iliffe.ca (SurgeMail 4.3e) with ESMTP id 2133-1594962 for ; Mon, 10 Dec 2012 15:27:27 -0500 From: John Iliffe To: users@httpd.apache.org Date: Mon, 10 Dec 2012 15:27:25 -0500 User-Agent: KMail/1.13.3 (Linux/2.6.33.7-desktop-2mnb; KDE/4.4.3; x86_64; ; ) References: <201212092018.22670.john.iliffe@iliffe.ca> In-Reply-To: <201212092018.22670.john.iliffe@iliffe.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212101527.25306.john.iliffe@iliffe.ca> X-Authenticated-User: john.iliffe@iliffe.ca X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Compilation error in Apache 2.4.3 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