LEDE now provides libncursesw by default [even for libncurses].
No need to keep this patch around.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python comes with it's own builtin libffi lib, which
seems easier to use for the host build, than trying
to use the one from the package feeds.
Also, dropping `005-fix-libffi-x86-64-configure.patch`
Not needed anymore.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Fixes: https://github.com/openwrt/packages/issues/3767
Since commit:
f6e6341d89
libressl is built on the host-side.
Python picks it up [ via the openssl/* headers ] and assumes
it has SSL libs.
Compiling works fine, linking fails.
Doesn't look like it's because:
2fd5ce9488
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Patch removing multiarch paths from build should be applied only when
Python is built for target, but not for host. When the paths are removed
during host build, host python throws some ugly errors when importing
some hashlib modules. Also it reports that modules crypt and nis failed
to build (tested on Ubuntu 14.04 host).
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
When cross-compiling, we do not need to add runtime lib dirs.
Also, the cross compilers that are used on OpenWRT do not support
the '-R' option, which causes build failures.
These build failures existed before, but were not noticed,
because it fails only on some setups.
This is because Python's `setup.py` does a lot of voo-doo
automagic that needs handling for some cross-compilation cases.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
When distutils are copying scripts, path to Python interpreter is adjusted.
This does not work well in OpenWrt buildroot, because the path is adjusted
to absolute path to host Python then. This patch simply disables the
adjusting of the path.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Try to reduce the amount of change in this patch, since it removes
a lot of stuff, when we could just 'ifdef' that stuff out, with 2 lines.
The buildroot project does something similar like this:
http://git.buildroot.net/buildroot/tree/package/python/005-pyc-pyo-conditional.patch
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems when cross compiling on x86_64 Debian (most likely Ubuntu too)
the host's paths will be added too causing build failures for some extensions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that the Python C extensions were being
(or at least trying to be) build using '/usr/include' as the first
include folder.
Seems this issue was already fixed on MacOS X and now we've extended
it for our case.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
According to PEP394 (http://legacy.python.org/dev/peps/pep-0394/)
the 'python' command should refer to 'python2'.
In our case, this means we should reboot the old python package.
We could rename the package name to python2, but that would
just complicate things a bit with other packages, and
since we're doing this reboot, such a complication would be
unnecessary.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some notes:
- Python 3 (at least version 3.4) is pretty cross-compiler-friendly,
so a lot of patches were thrown away.
- Arguments below were moved to ./files/config.site file, and disabled
ac_cv_have_chflags=no \
ac_cv_have_lchflags=no \
ac_cv_py_format_size_t=no \
ac_cv_have_long_long_format=yes \
ac_cv_buggy_getaddrinfo=no \
- --without-ensurepip added, because the build wants to ensure that
it works; that's a good idea, but for now, it requires special
setup, and we can do that later
- --without-pymalloc added, becase in Python 3, modules are suffixed
with m; e.g. so some paths are python3.4m instead of python3.4
all this is detailed here:
http://legacy.python.org/dev/peps/pep-3149/
Maybe it will be a good idea to re-add this back
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Alexandru Ardelean
Jan Čermák
Steven Barth
Alexandru Ardelean
Agent 42