All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, Don Slutz <dslutz@verizon.com>,
	1257099@bugs.launchpad.net, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [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	[thread overview]
Message-ID: <52ACBDAC.1040203@terremark.com> (raw)
In-Reply-To: <52A5C3FF.2030809@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3875 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 5692 bytes --]

[-- Attachment #2: 0001-configure-Disable-libtool-if-fPIE-does-not-work-with.patch --]
[-- Type: text/x-patch, Size: 3188 bytes --]

>From 4653e3e4df6abd55adb70b97cd8c7b1b10933a42 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
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 <dslutz@verizon.com>
---
 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 <<EOF
+
+void *f(unsigned char *buf, int len);
+void *g(unsigned char *buf, int len);
+
+void *
+f(unsigned char *buf, int len)
+{
+    return (void*)0L;
+}
+
+void *
+g(unsigned char *buf, int len)
+{
+    return f(buf, len);
+}
+
+EOF
+  if ! libtool_prog; then
+    echo "Disabling libtool due to broken toolchain support"
+    libtool=
+  fi
+fi
+
 if test "$pie" != "no" ; then
   cat > $TMPC << EOF
 
-- 
1.8.2.1



WARNING: multiple messages have this Message-ID (diff)
From: Don Slutz <dslutz@verizon.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, Don Slutz <dslutz@verizon.com>,
	1257099@bugs.launchpad.net, Richard Henderson <rth@twiddle.net>
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	[thread overview]
Message-ID: <52ACBDAC.1040203@terremark.com> (raw)
In-Reply-To: <52A5C3FF.2030809@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3875 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 5692 bytes --]

[-- Attachment #2: 0001-configure-Disable-libtool-if-fPIE-does-not-work-with.patch --]
[-- Type: text/x-patch, Size: 3188 bytes --]

>From 4653e3e4df6abd55adb70b97cd8c7b1b10933a42 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
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 <dslutz@verizon.com>
---
 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 <<EOF
+
+void *f(unsigned char *buf, int len);
+void *g(unsigned char *buf, int len);
+
+void *
+f(unsigned char *buf, int len)
+{
+    return (void*)0L;
+}
+
+void *
+g(unsigned char *buf, int len)
+{
+    return f(buf, len);
+}
+
+EOF
+  if ! libtool_prog; then
+    echo "Disabling libtool due to broken toolchain support"
+    libtool=
+  fi
+fi
+
 if test "$pie" != "no" ; then
   cat > $TMPC << EOF
 
-- 
1.8.2.1



  reply	other threads:[~2013-12-14 20:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-02 22:36 [Qemu-devel] [Bug 1257099] [NEW] QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error Don Slutz
2013-12-03 13:25 ` Stefano Stabellini
2013-12-03 13:25   ` Stefano Stabellini
2013-12-03 14:06   ` [Qemu-devel] " Paolo Bonzini
2013-12-03 14:06     ` Paolo Bonzini
2013-12-03 20:19     ` [Qemu-devel] " Don Slutz
2013-12-03 20:19       ` Don Slutz
2013-12-03 17:15   ` [Qemu-devel] " Paolo Bonzini
2013-12-03 17:15     ` Paolo Bonzini
2013-12-04  1:32 ` [Qemu-devel] " Don Slutz
2013-12-04  1:32   ` Don Slutz
2013-12-05 15:18   ` Paolo Bonzini
2013-12-05 15:18     ` Paolo Bonzini
2013-12-05 19:09     ` [Qemu-devel] " Don Slutz
2013-12-05 19:09       ` Don Slutz
2013-12-05 21:24     ` [Qemu-devel] " Richard Henderson
2013-12-05 21:24       ` Richard Henderson
2013-12-06  3:20       ` [Qemu-devel] " Don Slutz
2013-12-06  3:20         ` Don Slutz
2013-12-09 12:47         ` [Qemu-devel] " Don Slutz
2013-12-09 12:47           ` Don Slutz
2013-12-09 13:22           ` [Qemu-devel] " Paolo Bonzini
2013-12-09 13:22             ` Paolo Bonzini
2013-12-14 20:21             ` Don Slutz [this message]
2013-12-14 20:21               ` Don Slutz
2013-12-15 16:01               ` [Qemu-devel] " Don Slutz
2013-12-15 16:01                 ` Don Slutz
2013-12-07 13:27     ` [Qemu-devel] " Don Slutz
2013-12-07 13:27       ` Don Slutz
2016-09-28 14:56 ` [Qemu-devel] [Bug 1257099] " T. Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52ACBDAC.1040203@terremark.com \
    --to=dslutz@verizon.com \
    --cc=1257099@bugs.launchpad.net \
    --cc=Ian.Campbell@citrix.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.