QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error

[Don Slutz]

  lt LINK libcacard.la
/usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' 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
make[4]: *** [libcacard.la] Error 1
make[3]: *** [subdir-libcacard] Error 2

I have bisect'd this to:

dcs-xen-53:~/qemu>git-bisect next
00c705fb92bc6e69e955aeac3614e05ca02feacd is the first bad commit
commit 00c705fb92bc6e69e955aeac3614e05ca02feacd
Author: Paolo Bonzini <email address hidden>
Date: Tue May 29 11:40:24 2012 +0200

    build: libcacard Makefile cleanups

    Build vscclient from toplevel Makefile, limit usage of vpath.

    Signed-off-by: Paolo Bonzini <email address hidden>

:100644 100644 a10005a22fe44a107dfec15106960612b43be71f 1d34b9539e9ba47fdb7028ad0569389fa48712b9 M Makefile
:100644 100644 ae3770a5f718742838844f9064be6a7153ac7469 74110dda7e38b8ddae47a53ad4cb6ecf48231fa0 M Makefile.objs
:100644 100644 3dfdf925fdc2c92239b7053a3d4e09687dcc2171 555894db4aa717f15cfc24093d838131f422fc78 M Makefile.target
:100755 100755 e50ad0bb8fc2e331562f3c09e605af6597a143b1 cd5e8b349c137f621d2e9dc516145bc650d977c0 M configure
:040000 040000 160d565b7e551c3248333c9e49f34edb7a30f5e0 008bc3fccda52f78accf9494539ba62bfb1621a0 M libcacard

dcs-xen-53:~/qemu>git bisect log
git bisect start
# bad: [7457fe9541b5162f285454947448d553a5d5a531] Update version for v1.7.0-rc2 release
git bisect bad 7457fe9541b5162f285454947448d553a5d5a531
# good: [ed7ec8400707fe42f4a0f40db2f2d5827ecea789] Merge remote-tracking branch 'bonzini/scsi.2' into staging
git bisect good ed7ec8400707fe42f4a0f40db2f2d5827ecea789
# bad: [1d31fca470648ec66afd8743491bfb5846306341] qemu-barrier: Fix compilation on i386 hosts
git bisect bad 1d31fca470648ec66afd8743491bfb5846306341
# good: [9de36b1a7cf61aa8be365f13c81668b3e19fbc7f] Make -machine/-enable-kvm options merge into a single list
git bisect good 9de36b1a7cf61aa8be365f13c81668b3e19fbc7f
# bad: [3edb8f92e8b5f18797693d8ed9fad3962e11e25d] target-s390x: Pass S390CPU to s390_cpu_restart()
git bisect bad 3edb8f92e8b5f18797693d8ed9fad3962e11e25d
# good: [aecff6924dab0197b6c8f132e44502b25fd98a38] hw/arm_gic: Make gic_reset a sysbus reset function
git bisect good aecff6924dab0197b6c8f132e44502b25fd98a38
# good: [b9531b6eed93c9e1769d6f371c4da5d1f955e0d1] block/qcow2: Add missing GCC_FMT_ATTR to function report_unsupported()
git bisect good b9531b6eed93c9e1769d6f371c4da5d1f955e0d1
# good: [dd86df756e02b684718dd5378725927361b0ad36] Merge remote-tracking branch 'sstabellini/for_1.1_rc3' into staging
git bisect good dd86df756e02b684718dd5378725927361b0ad36
# good: [8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83] sun4u: Use cpu_sparc_init() to obtain SPARCCPU
git bisect good 8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83
# good: [8867aef02e1e5817c72b2e09be4ae952eb0c9d9d] build: move ui/ objects to nested Makefile.objs
git bisect good 8867aef02e1e5817c72b2e09be4ae952eb0c9d9d
# bad: [e8de1ea849176812765bf30514f66c5450a1edc6] target-xtensa: add attributes to helper functions
git bisect bad e8de1ea849176812765bf30514f66c5450a1edc6
# bad: [fa79c914efd35cb60e0bc18512c03690c48b13e2] Merge remote-tracking branch 'bonzini/nested-makefiles-3' into staging
git bisect bad fa79c914efd35cb60e0bc18512c03690c48b13e2
# good: [c353f261946ddbd814b333ae2440712b486977fd] build: move per-target hw/ objects to nested Makefile.objs
git bisect good c353f261946ddbd814b333ae2440712b486977fd
# bad: [25f27a4f7160d077d6992e811021b4bc3a82abc1] build: compile oslib-obj-y once
git bisect bad 25f27a4f7160d077d6992e811021b4bc3a82abc1
# bad: [00c705fb92bc6e69e955aeac3614e05ca02feacd] build: libcacard Makefile cleanups
git bisect bad 00c705fb92bc6e69e955aeac3614e05ca02feacd
# good: [49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45] build: move device tree to per-target Makefile.objs
git bisect good 49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45

[Don Slutz (dslutz)]

On 12/03/13 09:06, Paolo Bonzini wrote:
> Il 03/12/2013 14:25, Stefano Stabellini ha scritto:
>> CC'ing Paolo and xen-devel.
>> The original thread is here:
>>
>> http://marc.info/?l=xen-devel&m=135718999710640
>>
>> On Mon, 2 Dec 2013, Don Slutz wrote:
>>>> Public bug reported:
>>>>
>>>> lt LINK libcacard.la
>>>> /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' 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
>>>> make[4]: *** [libcacard.la] Error 1
>>>> make[3]: *** [subdir-libcacard] Error 2
> Thanks, I'll try to reproduce. Please send the "make V=1" output for a
> full build in the meanwhile.
Here it is for a full build of:

* 7dc65c0 (HEAD, origin/master, origin/HEAD, master) Open 2.0
development tree

   -Don Slutz
> Paolo

[Don Slutz (dslutz)]

On 12/03/13 12:15, Paolo Bonzini wrote:
> Il 03/12/2013 14:25, Stefano Stabellini ha scritto:
>> CC'ing Paolo and xen-devel.
>> The original thread is here:
>>
>> http://marc.info/?l=xen-devel&m=135718999710640
>>
>> On Mon, 2 Dec 2013, Don Slutz wrote:
>>> Public bug reported:
>>>
>>> lt LINK libcacard.la
>>> /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' 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
>>> make[4]: *** [libcacard.la] Error 1
>>> make[3]: *** [subdir-libcacard] Error 2
> This is a bug in RHEL5 binutils. Configure with --disable-pie to work
> around it.
Any hints or pointers about the bug in RHEL5 binutils? I can try and
make a patch to auto detect this.

That still fails for (7dc65c0 (HEAD, origin/master, origin/HEAD, master)
Open 2.0 development tree):

...
libtool --mode=link --tag=CC cc -m64 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
-Wold-style-definition -fstack-protector-all -I/usr/include/libpng12
-I/usr/include/nss3 -I/usr/include/nspr4 -pthread
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
-Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o
libcacard.la -Wc,-fstack-protector-all -lrt -pthread -L/lib64
-lgthread-2.0 -lglib-2.0 -lz -L/usr/kerberos/lib64 -lcurl -ldl
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid
cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -Wendif-labels
-Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k
-Winit-self -Wold-style-definition -fstack-protector-all
-I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
-Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o
-Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -L/lib64
-L/usr/kerberos/lib64 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4
-lnspr4 -lpthread -lrt -lgthread-2.0 -lglib-2.0 -lcurl -ldl
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz
-luuid -Wl,--rpath -Wl,/usr/local/lib
/usr/bin/ld: -f may not be used without -shared
collect2: ld returned 1 exit status
make: *** [vscclient] Error 1

Attached is the full "make V=1" output.

Here is the configure output:

dcs-xen-53:~/qemu>rm -rf out/tmp;mkdir out/tmp;pushd
out/tmp;../../configure --disable-pie;make V=1 1>z...

[Don Slutz (dslutz)]

On 12/05/13 10:18, Paolo Bonzini wrote:
> Il 04/12/2013 02:32, Don Slutz ha scritto:
>> Any hints or pointers about the bug in RHEL5 binutils? I can try and
>> make a patch to auto detect this.
> Actually it's RHEL5 GCC:
>
> $ cat f.c
> void *
> f(unsigned char *buf, int len)
> {
> return (void*)0L;
> }
>
>
> void *
> g(unsigned char *buf, int len)
> {
> return f(buf, len);
> }
> $ 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
>
> On RHEL5:
> $ gcc -S -o - f.c -fPIE -fPIC |grep call
> call f
>
> On RHEL6:
> $ gcc -S -o - f.c -fPIE -fPIC |grep call
> call f@PLT
>
> Paolo
How about this as a patch:

 From 282fba086186ff3b8e2b2b15e647df2b58d082dd Mon Sep 17 00:00:00 2001
From: Don Slutz <email address hidden>
Date: Thu, 5 Dec 2013 18:50:18 +0000
Subject: [PATCH] configure: Auto disabling of PIE due to broken toolchain
  support (bug #1257099)

See https://bugs.launchpad.net/bugs/1257099

On RHEL5 GCC, you can get 'relocation R_X86_64_PC32' errors from ld.
So disable PIE is this is true.

Signed-off-by: Don Slutz <email address hidden>
---
  configure | 43 +++++++++++++++++++++++++++++++++++--------
  1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index cf8123b..a51a9dd 100755
--- a/configure
+++ b/configure
@@ -1339,23 +1339,50 @@ if test "$pie" != "no" ; then
  # define THREAD
  #endif

+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);
+}
+
+#ifdef PIE
  static THREAD int tls_var;

  int main(void) { return tls_var; }
+#endif

  EOF
- if compile_prog "-fPIE -DPIE" "-pie"; then
- QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS"
- LDFLAGS="-pie $LDFLAGS"
- pie="yes"
- if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then
- LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS"
+ if compile_prog "-shared -fPIE -fPIC" ""; then
+ if compile_prog "-fPIE -DPIE" "-pie"; then
+ QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS"
+ LDFLAGS="-pie $LDFLAGS"
+ pie="yes"
+ if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then
+ LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS"
+ fi
+ else
+ if test "$pie" = "yes"; then
+ error_exit "PIE not available due to missing toolchain support"
+ else
+ echo "Disabling PIE due to missing toolchain support"
+ pie="no"
+ fi
      fi
    else
      if test "$pie" = "yes"; then
- error_exit "PIE not available due to missing toolchain support"
+ error_exit "PIE not available due to broken toolchain support"
      else
- echo "Disabling PIE due to missing toolchain support"
+ echo "Disabling P...

[Richard Henderson (rth)]

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~

[Don Slutz (dslutz)]

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~
Here is a possible patch based on this statement:

 From 6e57382c58fa1b9be0fe9db8f35f53a7a7858ccd Mon Sep 17 00:00:00 2001
From: Don Slutz <email address hidden>
Date: Fri, 6 Dec 2013 03:12:12 +0000
Subject: [PATCH] configure: Auto disabling of libtool due to broken
toolchain
  support (bug #1257099)

See https://bugs.launchpad.net/bugs/1257099

On RHEL5 GCC with libtool and PIE, you get 'relocation R_X86_64_PC32'
errors from ld.
So disable libtool which disables smartcard-nss (aka nss) if this is true.

Signed-off-by: Don Slutz <email address hidden>
---
  configure | 27 +++++++++++++++++++++++++++
  1 file changed, 27 insertions(+)

diff --git a/configure b/configure
index 0666228..5e34095 100755
--- a/configure
+++ b/configure
@@ -1310,6 +1310,33 @@ if compile_prog "-Werror -fno-gcse" "" ; then
    TRANSLATE_OPT_CFLAGS=-fno-gcse
  fi

+# check for broken GCC in RHEL5 with PIE
+if test -n "$libtool" -a "$pie" = "" ; 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 ! compile_prog "-shared -fPIE -fPIC" ""; then
+ echo "Disabling libtool due to broken toolchain support"
+ echo "Defaulting to --disable-smartcard-nss"
+ libtool=
+ fi
+fi
+
  if test "$static" = "yes" ; then
    if test "$pie" = "yes" ; then
      error_exit "static and pie are mutually incompatible"
--
1.8.2.1

   -Don Slutz

[Don Slutz (dslutz)]

On 12/05/13 10:18, Paolo Bonzini wrote:
> Il 04/12/2013 02:32, Don Slutz ha scritto:
>> Any hints or pointers about the bug in RHEL5 binutils? I can try and
>> make a patch to auto detect this.
> Actually it's RHEL5 GCC:
>
> $ cat f.c
> void *
> f(unsigned char *buf, int len)
> {
> return (void*)0L;
> }
>
>
> void *
> g(unsigned char *buf, int len)
> {
> return f(buf, len);
> }
> $ 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
>
> On RHEL5:
> $ gcc -S -o - f.c -fPIE -fPIC |grep call
> call f
>
> On RHEL6:
> $ gcc -S -o - f.c -fPIE -fPIC |grep call
> call f@PLT
>
> Paolo
RHEL5 also "works" if you add -pie:

dcs-xen-53:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC
/usr/bin/ld: /tmp/cc6pp1n2.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>gcc -shared -o f.so f.c -fPIE -fPIC -pie
dcs-xen-53:~/tmp>gcc -S -o - f.c -fPIE -pie|grep call
         call f

I have not figured out a way to take advantage of this.

I just checked and Fedora 17 has the same issue with gcc:
FC17:
dcs-xen-52:~/tmp>gcc -S -o - f.c -fPIE -fPIC |grep call
         call f
dcs-xen-52:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC
/usr/bin/ld: /tmp/ccUlVgMP.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

However QEMU builds just fine. So it is looking like libtool is also
part of the problem.

    -Don Slutz

[Don Slutz (dslutz)]

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.

    -Don Slutz

[Don Slutz (dslutz)]

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>libto...

[Don Slutz (dslutz)]

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 makin...

[Don Slutz (dslutz)]

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 <email address hidden>
---
Was posted as an attachment.

https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html

 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

[Don Slutz (dslutz)]

On 01/02/14 21:12, Don Slutz wrote:

Ping.

> 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 <email address hidden>
> ---
> Was posted as an attachment.
>
> https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html
>
> 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=
> + f...

[Thomas Huth (th-huth)]

Patch has been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=66518bf668f09eaab14c174
==> Fix released.