| Summary: | dev-lang/python builds an internal copy of libffi | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | esigra, Gordeev, n-roeser, rhill, ssuominen |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 199850, 272046, 287383 | ||
| Bug Blocks: | 251464, 212178 | ||
| Attachments: | Detect standard includes instead of guessing. | ||
|
Description
Diego Elio Pettenò (RETIRED)
2008-02-11 16:23:25 UTC
right, the ctypes Module seems to include a development snapshot of the 2.x version of libffi. and there is a configure-switch: --with-system-ffi But I really want the libffi USE-flag set per default for sys-devel/gcc if we're going to enable this. And add a big fat warning that recompiling gcc without it can break portage badly. Or am I missunderstanding something, Diego? Can't we get it forced on by profile? (so that when building for embedded or custom systems one can disable it by changing package.use.mask, rather than ebuild, but then the profiles will disallow "normal" users from breaking everything...) That sounds good. Can you take care of this please? :-) Python's detection of an available system-ffi is broken (of course). They try to detect ffi.h and libffi.so by manually searching the paths but forget the implicit dirs "/usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.3/include", resp. "/usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.3" and therefore fail _silently_ (*argh*). Appending those as include-, resp. library-dirs to CFLAGS solves the issue but then you end up with those flags for everything in python. I really don't feel comfortable with that solution... with a little patch it works perfectly without messing with the CFLAGS.
Maybe someone can come up with a nice patch (like adding --with-system-ffi-{incdir,libdir} flags to configure...)
--- Python-2.5.1/setup.py 2007-02-14 13:53:41.000000000 +0100
+++ Python-2.5.1.new/setup.py 2008-03-03 17:01:08.000000000 +0100
@@ -1306,7 +1306,7 @@
# -lGL -lGLU -lXext -lXmu \
def configure_ctypes(self, ext):
- if not self.use_system_libffi:
+ if False:
(srcdir,) = sysconfig.get_config_vars('srcdir')
ffi_builddir = os.path.join(self.build_temp, 'libffi')
ffi_srcdir = os.path.abspath(os.path.join(srcdir, 'Modules',
@@ -1390,6 +1390,7 @@
ext_test = Extension('_ctypes_test',
sources=['_ctypes/_ctypes_test.c'])
self.extensions.extend([ext, ext_test])
+ ext.libraries.append('ffi')
if not '--with-system-ffi' in sysconfig.get_config_var("CONFIG_ARGS"):
return
Created attachment 146690 [details, diff]
Detect standard includes instead of guessing.
An alternative is for setup.py to detect the standard include directories. I made my own patch for setup.py that get's the standard C include directories by running 'cpp -v </dev/null'. It's made against 2.5.2, but it applies on 2.5.1 as well.
is libffi stable across GCC versions? will something like switching from 4.3.0 to 3.3.3 with gcc-config cause problems? I doubt switching gcc versions will cause problems. Because of libffi's stagnant development, gcc has been using the same snapshot of libffi for ten years. Python has been using the same version of libffi, but they're switching in their 2.6 release to libffi-3.0.4 (released 2008-02-24). So, I don't think it's a good idea to use gcc's libffi if everything changes in the next release of python. The only solution I see is to add the new libffi to portage and get gcc and python to use it. (In reply to comment #9) > So, I don't think it's a good idea to use gcc's libffi if everything changes in > the next release of python. The only solution I see is to add the new libffi > to portage and get gcc and python to use it. > Agreed. /me votes for RESO LATER. Other python devs, please comment. an external libffi package is what we had up until now and it rotted. gcc will always need to use it's internal copy. i recommend python does too. the number of external libraries needed for both gcc and python should be kept to a bare minimum. The new, and apparently maintained libffi is now unmasked and that is what other distibutions use also. It's at a KEYWORDREQ state in bug 272046. Please make python use virtual/libffi is possible. (In reply to comment #12) > The new, and apparently maintained libffi is now unmasked and that is what > other distibutions use also. It's at a KEYWORDREQ state in bug 272046. > > Please make python use virtual/libffi is possible. > And it's now also keyworded, please move forward on using virtual/libffi instead of internal copy. (In reply to comment #13) > And it's now also keyworded, please move forward on using virtual/libffi > instead of internal copy. It isn't keyworded yet on m68k, mips, sparc-fbsd and x86-fbsd. dev-lang/python has keywords on these architectures. (In reply to comment #14) > (In reply to comment #13) > > And it's now also keyworded, please move forward on using virtual/libffi > > instead of internal copy. > > It isn't keyworded yet on m68k, mips, sparc-fbsd and x86-fbsd. > dev-lang/python has keywords on these architectures. > And arch ia64 python version 2.5.4-r3, 2.6.2.-r1, 3.1.1 does't compile. External libffi is now used on all architectures except m68k, mips, sparc-fbsd and x86-fbsd in dev-lang/python-2.6.2-r2 and dev-lang/python-3.1.1-r1. (In reply to comment #16) > External libffi is now used on all architectures except m68k, mips, > sparc-fbsd and x86-fbsd in dev-lang/python-2.6.2-r2 and > dev-lang/python-3.1.1-r1. I have decided to remove this workaround and ask the remaining architectures for rekeywording in bug #287383. The (re)keywording has been done for all arch's, closing this bug... External libffi is now used also in dev-lang/python-2.5.4-r4. |