From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vrvi4-00066v-QP for qemu-devel@nongnu.org; Sat, 14 Dec 2013 15:21:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vrvhy-0001DT-TV for qemu-devel@nongnu.org; Sat, 14 Dec 2013 15:21:12 -0500 Received: from fldsmtpe02.verizon.com ([140.108.26.141]:48167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vrvhy-0001DK-MS for qemu-devel@nongnu.org; Sat, 14 Dec 2013 15:21:06 -0500 From: Don Slutz Message-ID: <52ACBDAC.1040203@terremark.com> Date: Sat, 14 Dec 2013 15:21:00 -0500 MIME-Version: 1.0 References: <20131202223641.6000.456.malonedeb@chaenomeles.canonical.com> <20131202223641.6000.456.malonedeb@chaenomeles.canonical.com> <529E1194.9060504@redhat.com> <529E8638.2010102@terremark.com> <52A09933.5090302@redhat.com> <52A0EF2B.9000905@twiddle.net> <52A1427D.6000307@terremark.com> <52A5BBE6.9070000@terremark.com> <52A5C3FF.2030809@redhat.com> In-Reply-To: <52A5C3FF.2030809@redhat.com> Content-Type: multipart/mixed; boundary="------------030302010702020305090809" Subject: Re: [Qemu-devel] [Bug 1257099] [NEW] QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: xen-devel@lists.xensource.com, Ian Campbell , Stefano Stabellini , qemu-devel@nongnu.org, Don Slutz , 1257099@bugs.launchpad.net, Richard Henderson --------------030302010702020305090809 Content-Type: multipart/alternative; boundary="------------000604080900000707020405" --------------000604080900000707020405 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 12/09/13 08:22, Paolo Bonzini wrote: > Il 09/12/2013 13:47, Don Slutz ha scritto: >> On 12/05/13 22:20, Don Slutz wrote: >>> On 12/05/13 16:24, Richard Henderson wrote: >>>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: >>>>> $ gcc -shared -o f.so f.c -fPIE -fPIC >>>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' >>>>> can not be used when making a shared object; recompile with -fPIC >>>>> /usr/bin/ld: final link failed: Bad value >>>>> collect2: ld returned 1 exit status >>>>> >>>>> >>>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: >>>>> >>>>> $ gcc -S -o - f.c -fPIE |grep call >>>>> call f # PC32 relocation >>>>> $ gcc -S -o - f.c -fPIC |grep call >>>>> call f@PLT # PLT32 relocation >>>> The easy workaround is to drop -fPIE when we're adding -fPIC. >>>> >>>> >>>> r~ >> [snip] >> >> Attached is a much better version. It drops -fPIE and adds -fPIC for >> libtool. > It's not much better, because using position-independent code for shared > libraries is really platform-dependent knowledge of the kind that > libtool is supposed to hide. > > For example, on Mac OS X everything is position-independent by default. > And on some platforms you have -fpic instead of -fPIC. > > So I prefer the patch you had that disabled libtool if the platform is > buggy. > > Paolo Well, the detection code is too simple: FC17 system: dcs-xen-52:~/tmp/libtool>uname -a Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so /usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against symbol `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c libtool: compile: gcc -g -c -DPIE f.c -fPIC -DPIC -o .libs/f.o libtool: compile: gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1 dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib libtool: link: gcc -shared -fPIC -DPIC .libs/f.o -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0 libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s "libf.so.0.0.0" "libf.so.0") libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s "libf.so.0.0.0" "libf.so") libtool: link: ar cru .libs/libf.a f.o libtool: link: ranlib .libs/libf.a libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s "../libf.la" "libf.la" ) CentOS 5.10: dcs-xen-53:~/tmp/libtool>uname -a Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so /usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c mkdir .libs gcc -g -c -fPIE -DPIE f.c -fPIC -DPIC -o .libs/f.o gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1 dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib gcc -shared .libs/f.o -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0 /usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status I have attached a patch that uses libtool to determine if gcc & libtool is broken. -Don --------------000604080900000707020405 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 12/09/13 08:22, Paolo Bonzini wrote:
Il 09/12/2013 13:47, Don Slutz ha scritto:

On 12/05/13 22:20, Don Slutz wrote:

On 12/05/13 16:24, Richard Henderson wrote:

On 12/06/2013 04:18 AM, Paolo Bonzini wrote:

$ gcc -shared -o f.so f.c -fPIE -fPIC
/usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f'
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC:

$ gcc -S -o - f.c -fPIE |grep call
    call    f                      # PC32 relocation
$ gcc -S -o - f.c -fPIC |grep call
    call    f@PLT                  # PLT32 relocation

The easy workaround is to drop -fPIE when we're adding -fPIC.


r~

[snip]

Attached is a much better version.  It drops -fPIE and adds -fPIC for
libtool.

It's not much better, because using position-independent code for shared
libraries is really platform-dependent knowledge of the kind that
libtool is supposed to hide.

For example, on Mac OS X everything is position-independent by default.
 And on some platforms you have -fpic instead of -fPIC.

So I prefer the patch you had that disabled libtool if the platform is
buggy.

Paolo
Well, the detection code is too simple:

FC17 system:
dcs-xen-52:~/tmp/libtool>uname -a
Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c  -fPIC -DPIC -o f.so
/usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against symbol `f' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c
libtool: compile:  gcc -g -c -DPIE f.c  -fPIC -DPIC -o .libs/f.o
libtool: compile:  gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1
dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib
libtool: link: gcc -shared  -fPIC -DPIC  .libs/f.o      -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s "libf.so.0.0.0" "libf.so.0")
libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s "libf.so.0.0.0" "libf.so")
libtool: link: ar cru .libs/libf.a  f.o
libtool: link: ranlib .libs/libf.a
libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s "../libf.la" "libf.la" )
CentOS 5.10:
dcs-xen-53:~/tmp/libtool>uname -a
Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c  -fPIC -DPIC -o f.so
/usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c
mkdir .libs
 gcc -g -c -fPIE -DPIE f.c  -fPIC -DPIC -o .libs/f.o
 gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1
dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib
gcc -shared  .libs/f.o   -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0
/usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
I have attached a patch that uses libtool to determine if gcc & libtool is broken.
     -Don

--------------000604080900000707020405-- --------------030302010702020305090809 Content-Type: text/x-patch; name="0001-configure-Disable-libtool-if-fPIE-does-not-work-with.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-configure-Disable-libtool-if-fPIE-does-not-work-with.pa"; filename*1="tch" >>From 4653e3e4df6abd55adb70b97cd8c7b1b10933a42 Mon Sep 17 00:00:00 2001 From: Don Slutz Date: Sat, 14 Dec 2013 19:43:56 +0000 Subject: [PATCH] configure: Disable libtool if -fPIE does not work with it (bug #1257099) Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names to be fixed (TMPB). Add new functions do_libtool and libtool_prog. Add check for broken gcc and libtool. Signed-off-by: Don Slutz --- configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 62 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 0666228..ead34ae 100755 --- a/configure +++ b/configure @@ -12,7 +12,10 @@ else fi TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" -TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" +TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" +TMPO="${TMPDIR1}/${TMPB}.o" +TMPL="${TMPDIR1}/${TMPB}.lo" +TMPA="${TMPDIR1}/lib${TMPB}.la" TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" # NB: do not call "exit" in the trap handler; this is buggy with some shells; @@ -86,6 +89,38 @@ compile_prog() { do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags } +do_libtool() { + local mode=$1 + shift + # Run the compiler, capturing its output to the log. + echo $libtool $mode --tag=CC $cc "$@" >> config.log + $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? + # Test passed. If this is an --enable-werror build, rerun + # the test with -Werror and bail out if it fails. This + # makes warning-generating-errors in configure test code + # obvious to developers. + if test "$werror" != "yes"; then + return 0 + fi + # Don't bother rerunning the compile if we were already using -Werror + case "$*" in + *-Werror*) + return 0 + ;; + esac + echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log + $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $? + error_exit "configure test passed without -Werror but failed with -Werror." \ + "This is probably a bug in the configure script. The failing command" \ + "will be at the bottom of config.log." \ + "You can run configure with --disable-werror to bypass this check." +} + +libtool_prog() { + do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? + do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib +} + # symbolically link $1 to $2. Portable version of "ln -sf". symlink() { rm -rf "$2" @@ -1328,6 +1363,32 @@ if test "$pie" = ""; then esac fi +# check for broken gcc and libtool in RHEL5 +if test -n "$libtool" -a "$pie" != "no" ; then + cat > $TMPC < $TMPC << EOF -- 1.8.2.1 --------------030302010702020305090809-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [Bug 1257099] [NEW] QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error Date: Sat, 14 Dec 2013 15:21:00 -0500 Message-ID: <52ACBDAC.1040203@terremark.com> References: <20131202223641.6000.456.malonedeb@chaenomeles.canonical.com> <20131202223641.6000.456.malonedeb@chaenomeles.canonical.com> <529E1194.9060504@redhat.com> <529E8638.2010102@terremark.com> <52A09933.5090302@redhat.com> <52A0EF2B.9000905@twiddle.net> <52A1427D.6000307@terremark.com> <52A5BBE6.9070000@terremark.com> <52A5C3FF.2030809@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030302010702020305090809" Return-path: In-Reply-To: <52A5C3FF.2030809@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Paolo Bonzini Cc: xen-devel@lists.xensource.com, Ian Campbell , Stefano Stabellini , qemu-devel@nongnu.org, Don Slutz , 1257099@bugs.launchpad.net, Richard Henderson List-Id: xen-devel@lists.xenproject.org --------------030302010702020305090809 Content-Type: multipart/alternative; boundary="------------000604080900000707020405" --------------000604080900000707020405 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 12/09/13 08:22, Paolo Bonzini wrote: > Il 09/12/2013 13:47, Don Slutz ha scritto: >> On 12/05/13 22:20, Don Slutz wrote: >>> On 12/05/13 16:24, Richard Henderson wrote: >>>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: >>>>> $ gcc -shared -o f.so f.c -fPIE -fPIC >>>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' >>>>> can not be used when making a shared object; recompile with -fPIC >>>>> /usr/bin/ld: final link failed: Bad value >>>>> collect2: ld returned 1 exit status >>>>> >>>>> >>>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: >>>>> >>>>> $ gcc -S -o - f.c -fPIE |grep call >>>>> call f # PC32 relocation >>>>> $ gcc -S -o - f.c -fPIC |grep call >>>>> call f@PLT # PLT32 relocation >>>> The easy workaround is to drop -fPIE when we're adding -fPIC. >>>> >>>> >>>> r~ >> [snip] >> >> Attached is a much better version. It drops -fPIE and adds -fPIC for >> libtool. > It's not much better, because using position-independent code for shared > libraries is really platform-dependent knowledge of the kind that > libtool is supposed to hide. > > For example, on Mac OS X everything is position-independent by default. > And on some platforms you have -fpic instead of -fPIC. > > So I prefer the patch you had that disabled libtool if the platform is > buggy. > > Paolo Well, the detection code is too simple: FC17 system: dcs-xen-52:~/tmp/libtool>uname -a Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so /usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against symbol `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c libtool: compile: gcc -g -c -DPIE f.c -fPIC -DPIC -o .libs/f.o libtool: compile: gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1 dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib libtool: link: gcc -shared -fPIC -DPIC .libs/f.o -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0 libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s "libf.so.0.0.0" "libf.so.0") libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s "libf.so.0.0.0" "libf.so") libtool: link: ar cru .libs/libf.a f.o libtool: link: ranlib .libs/libf.a libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s "../libf.la" "libf.la" ) CentOS 5.10: dcs-xen-53:~/tmp/libtool>uname -a Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so /usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c mkdir .libs gcc -g -c -fPIE -DPIE f.c -fPIC -DPIC -o .libs/f.o gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1 dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib gcc -shared .libs/f.o -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0 /usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status I have attached a patch that uses libtool to determine if gcc & libtool is broken. -Don --------------000604080900000707020405 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 12/09/13 08:22, Paolo Bonzini wrote:
Il 09/12/2013 13:47, Don Slutz ha scritto:

On 12/05/13 22:20, Don Slutz wrote:

On 12/05/13 16:24, Richard Henderson wrote:

On 12/06/2013 04:18 AM, Paolo Bonzini wrote:

$ gcc -shared -o f.so f.c -fPIE -fPIC
/usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f'
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC:

$ gcc -S -o - f.c -fPIE |grep call
    call    f                      # PC32 relocation
$ gcc -S -o - f.c -fPIC |grep call
    call    f@PLT                  # PLT32 relocation

The easy workaround is to drop -fPIE when we're adding -fPIC.


r~

[snip]

Attached is a much better version.  It drops -fPIE and adds -fPIC for
libtool.

It's not much better, because using position-independent code for shared
libraries is really platform-dependent knowledge of the kind that
libtool is supposed to hide.

For example, on Mac OS X everything is position-independent by default.
 And on some platforms you have -fpic instead of -fPIC.

So I prefer the patch you had that disabled libtool if the platform is
buggy.

Paolo
Well, the detection code is too simple:

FC17 system:
dcs-xen-52:~/tmp/libtool>uname -a
Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c  -fPIC -DPIC -o f.so
/usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against symbol `f' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c
libtool: compile:  gcc -g -c -DPIE f.c  -fPIC -DPIC -o .libs/f.o
libtool: compile:  gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1
dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib
libtool: link: gcc -shared  -fPIC -DPIC  .libs/f.o      -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s "libf.so.0.0.0" "libf.so.0")
libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s "libf.so.0.0.0" "libf.so")
libtool: link: ar cru .libs/libf.a  f.o
libtool: link: ranlib .libs/libf.a
libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s "../libf.la" "libf.la" )
CentOS 5.10:
dcs-xen-53:~/tmp/libtool>uname -a
Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c  -fPIC -DPIC -o f.so
/usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE -DPIE f.c
mkdir .libs
 gcc -g -c -fPIE -DPIE f.c  -fPIC -DPIC -o .libs/f.o
 gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1
dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo -rpath /usr/local/lib
gcc -shared  .libs/f.o   -Wl,-soname -Wl,libf.so.0 -o .libs/libf.so.0.0.0
/usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
I have attached a patch that uses libtool to determine if gcc & libtool is broken.
     -Don

--------------000604080900000707020405-- --------------030302010702020305090809 Content-Type: text/x-patch; name="0001-configure-Disable-libtool-if-fPIE-does-not-work-with.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-configure-Disable-libtool-if-fPIE-does-not-work-with.pa"; filename*1="tch" >>From 4653e3e4df6abd55adb70b97cd8c7b1b10933a42 Mon Sep 17 00:00:00 2001 From: Don Slutz Date: Sat, 14 Dec 2013 19:43:56 +0000 Subject: [PATCH] configure: Disable libtool if -fPIE does not work with it (bug #1257099) Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names to be fixed (TMPB). Add new functions do_libtool and libtool_prog. Add check for broken gcc and libtool. Signed-off-by: Don Slutz --- configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 62 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 0666228..ead34ae 100755 --- a/configure +++ b/configure @@ -12,7 +12,10 @@ else fi TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" -TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" +TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" +TMPO="${TMPDIR1}/${TMPB}.o" +TMPL="${TMPDIR1}/${TMPB}.lo" +TMPA="${TMPDIR1}/lib${TMPB}.la" TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" # NB: do not call "exit" in the trap handler; this is buggy with some shells; @@ -86,6 +89,38 @@ compile_prog() { do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags } +do_libtool() { + local mode=$1 + shift + # Run the compiler, capturing its output to the log. + echo $libtool $mode --tag=CC $cc "$@" >> config.log + $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? + # Test passed. If this is an --enable-werror build, rerun + # the test with -Werror and bail out if it fails. This + # makes warning-generating-errors in configure test code + # obvious to developers. + if test "$werror" != "yes"; then + return 0 + fi + # Don't bother rerunning the compile if we were already using -Werror + case "$*" in + *-Werror*) + return 0 + ;; + esac + echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log + $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $? + error_exit "configure test passed without -Werror but failed with -Werror." \ + "This is probably a bug in the configure script. The failing command" \ + "will be at the bottom of config.log." \ + "You can run configure with --disable-werror to bypass this check." +} + +libtool_prog() { + do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? + do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib +} + # symbolically link $1 to $2. Portable version of "ln -sf". symlink() { rm -rf "$2" @@ -1328,6 +1363,32 @@ if test "$pie" = ""; then esac fi +# check for broken gcc and libtool in RHEL5 +if test -n "$libtool" -a "$pie" != "no" ; then + cat > $TMPC < $TMPC << EOF -- 1.8.2.1 --------------030302010702020305090809--