classification
Title: libffi assembler relocation check is not robust, fails with clang
Type: behavior Stage: resolved
Components: Build Versions: Python 3.4, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: skrah Nosy List: Arfrever, benjamin.peterson, doko, donmez, eric.araujo, koobs, pitrou, python-dev, skrah
Priority: normal Keywords:

Created on 2011-03-31 12:38 by donmez, last changed 2013-04-30 08:05 by python-dev. This issue is now closed.

Messages (21)
msg132663 - (view) Author: Ismail Donmez (donmez) * Date: 2011-03-31 12:38
The check under Modules/_ctypes/libffi/configure.ac does;

    echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s
    if $CC $CFLAGS -c conftest.s 2>&1 | grep -i warning > /dev/null; then
        libffi_cv_as_x86_pcrel=no
    fi  

With clang; we get:

clang: warning: argument unused during compilation: '-g'

So it fails to detect pc relocation support due to an unrelated warning.
msg132675 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-03-31 15:06
I suggest you complain to the libffi maintainers.
msg132676 - (view) Author: Ismail Donmez (donmez) * Date: 2011-03-31 15:12
This is already fixed in upstream, check has been changed into:

libffi_cv_as_x86_pcrel=no
echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s
if $CC $CFLAGS -c conftest.s > /dev/null; then
libffi_cv_as_x86_pcrel=yes
fi
])
msg132677 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * Date: 2011-03-31 15:16
You can install the newest libffi and pass --with-system-ffi option to main `configure` of Python.
msg132679 - (view) Author: Ismail Donmez (donmez) * Date: 2011-03-31 15:17
Yes I can workaround it but I'd like to get it fixed inside Python too ;)
msg132680 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * Date: 2011-03-31 15:25
Internal copies of third-party libraries are rather always outdated, so it's better to always use system libraries. IMHO Python shouldn't bundle any third-party libraries and should force users to use system libraries. At least, system libraries could be used by default and main `configure` could accept --with-internal-expat and --with-internal-libffi options.
msg135233 - (view) Author: Ismail Donmez (donmez) * Date: 2011-05-05 19:10
Ping? Shall I submit a fix for Modules/_ctypes/libffi/configure.ac or better yet will you sync in-tree libffi?
msg135234 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-05 19:13
Well, ctypes is kindof unmaintained right now, and the private libffi copy belongs to that module.
(the reason we have a libffi copy is that, IIUC, it's patched)
msg135236 - (view) Author: Ismail Donmez (donmez) * Date: 2011-05-05 19:17
Patch for configure.ac then?
msg136639 - (view) Author: √Čric Araujo (eric.araujo) * (Python committer) Date: 2011-05-23 14:00
See also #12081.
msg180103 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2013-01-16 19:19
In 3.3 libffi has been updated to 3.0.11. Our clang buildbot does not
show this particular warning, but still fails to compile libffi:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.3/builds/320/steps/compile/logs/stdio


It would help if you provided a link to the upstream patch.
msg180105 - (view) Author: Ismail Donmez (donmez) * Date: 2013-01-16 19:42
See http://sourceware.org/ml/libffi-discuss/2011/msg00024.html for the libffi patch.
msg180114 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-16 22:27
New changeset 190a115b7748 by Stefan Krah in branch '3.3':
Issue #11729: Backport commit bff052d9 from libffi upstream in order to fix
http://hg.python.org/cpython/rev/190a115b7748
msg180115 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2013-01-16 22:35
Thanks for the link. The diff was committed last week to the upstream
libffi development tree, so I backported it.
msg180182 - (view) Author: Kubilay Kocak (koobs) Date: 2013-01-18 10:15
Stefan, can we merge this to the 2.7 branch as well please?

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%202.7/builds/308/steps/compile/logs/stdio
msg180184 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2013-01-18 10:36
koobs <report@bugs.python.org> wrote:
> Stefan, can we merge this to the 2.7 branch as well please?

If Benjamin is okay with it, yes.  The problem with these configure fixes
is that they might break other systems in unexpected ways. I already hesitated
to put it into 3.3, but the buildbots are fine.
msg180185 - (view) Author: Kubilay Kocak (koobs) Date: 2013-01-18 10:38
Thanks for the quick response. I'd be happy for it to be FreeBSD conditional/specific if that's more suitable, safer?

Having said that, our buildbot OS coverage is pretty good, no?
msg180243 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2013-01-19 12:47
The buildbot coverage is good, but the number of (OS, shell, compiler)
combinations is much higher.
msg180771 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-01-27 15:15
Okay with me to backport.
msg180776 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-27 17:01
New changeset b9792b27d410 by Stefan Krah in branch '2.7':
Issue #11729: Backport commit bff052d9 from libffi upstream in order to fix
http://hg.python.org/cpython/rev/b9792b27d410
msg188141 - (view) Author: Roundup Robot (python-dev) Date: 2013-04-30 08:05
New changeset 7a2e0c1bb1a9 by Gregory P. Smith in branch '3.2':
* Fix issue 17192 for 3.2 - reapply the issue11729 patch that was undone
http://hg.python.org/cpython/rev/7a2e0c1bb1a9

New changeset aa3371fa9773 by Gregory P. Smith in branch '3.3':
* Fix PART of issue 17192 for 3.3 - reapply the issue11729 patch
http://hg.python.org/cpython/rev/aa3371fa9773

New changeset e0fdc21c7d13 by Gregory P. Smith in branch 'default':
* Fix PART of issue 17192 for 3.4 - reapply the issue11729 patch
http://hg.python.org/cpython/rev/e0fdc21c7d13
History
Date User Action Args
2013-04-30 08:05:39python-devsetmessages: + msg188141
2013-01-27 17:01:56python-devsetmessages: + msg180776
2013-01-27 15:15:43benjamin.petersonsetmessages: + msg180771
2013-01-19 12:47:16skrahsetmessages: + msg180243
2013-01-18 10:38:50koobssetmessages: + msg180185
2013-01-18 10:36:53skrahsetmessages: + msg180184
2013-01-18 10:15:10koobssetnosy: + koobs
messages: + msg180182
2013-01-17 13:19:39skrahlinkissue12812 superseder
2013-01-16 22:35:47skrahsetstatus: open -> closed

assignee: skrah
versions: + Python 3.4
messages: + msg180115
type: behavior
resolution: fixed
stage: resolved
2013-01-16 22:27:09python-devsetnosy: + python-dev
messages: + msg180114
2013-01-16 19:42:20donmezsetmessages: + msg180105
2013-01-16 19:19:28skrahsetnosy: + skrah
messages: + msg180103
2013-01-16 18:51:50brett.cannonsetnosy: - brett.cannon
2011-05-23 14:00:18eric.araujosetnosy: + eric.araujo
messages: + msg136639
2011-05-05 19:17:32donmezsetmessages: + msg135236
2011-05-05 19:13:58pitrousetnosy: + doko
2011-05-05 19:13:10pitrousetnosy: + pitrou
messages: + msg135234
2011-05-05 19:10:27donmezsetmessages: + msg135233
2011-03-31 17:57:29rhettingersetnosy: + brett.cannon
2011-03-31 15:25:58Arfreversetmessages: + msg132680
2011-03-31 15:17:52donmezsetmessages: + msg132679
2011-03-31 15:16:05Arfreversetnosy: + Arfrever
messages: + msg132677
2011-03-31 15:12:50donmezsetmessages: + msg132676
2011-03-31 15:06:24benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg132675
2011-03-31 12:38:37donmezcreate