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: Sun, 15 Dec 2013 11:01:54 -0500 [thread overview]
Message-ID: <52ADD272.6060109@terremark.com> (raw)
In-Reply-To: <52ACBDAC.1040203@terremark.com>
[-- Attachment #1.1: Type: text/plain, Size: 7538 bytes --]
On 12/14/13 15:21, Don Slutz wrote:
> 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
>
Early today it hit me that the new check was a little to early in
configure. Needs to be after PIE check.
Attached is a v2 of the patch.
-Don Slutz
From bb68898eb787cbb1748d4aeb31a4184339d38300 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 edfea95..852d021 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"
@@ -1367,6 +1402,32 @@ EOF
fi
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
+
##########################################
# __sync_fetch_and_and requires at least -march=i486. Many toolchains
# use i686 as default anyway, but for those that don't, an explicit
--
1.8.2.1
[-- Attachment #1.2: Type: text/html, Size: 11793 bytes --]
[-- Attachment #2: 0001-configure-Disable-libtool-if-fPIE-does-not-work-with.patch --]
[-- Type: text/x-patch, Size: 3431 bytes --]
>From bb68898eb787cbb1748d4aeb31a4184339d38300 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Sat, 14 Dec 2013 19:43:56 +0000
Subject: [PATCH v2] 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>
---
Changes v1 to v2: Move the libtool check to after the PIE check. No need to disable
libtool not working with PIE if PIE is not used.
configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index edfea95..852d021 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"
@@ -1367,6 +1402,32 @@ EOF
fi
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
+
##########################################
# __sync_fetch_and_and requires at least -march=i486. Many toolchains
# use i686 as default anyway, but for those that don't, an explicit
--
1.8.2.1
next prev parent reply other threads:[~2013-12-15 16:02 UTC|newest]
Thread overview: 16+ 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 14:06 ` Paolo Bonzini
2013-12-03 20:19 ` Don Slutz
2013-12-03 17:15 ` Paolo Bonzini
2013-12-04 1:32 ` Don Slutz
2013-12-05 15:18 ` Paolo Bonzini
2013-12-05 19:09 ` Don Slutz
2013-12-05 21:24 ` Richard Henderson
2013-12-06 3:20 ` Don Slutz
2013-12-09 12:47 ` Don Slutz
2013-12-09 13:22 ` Paolo Bonzini
2013-12-14 20:21 ` Don Slutz
2013-12-15 16:01 ` Don Slutz [this message]
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=52ADD272.6060109@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).