Using this minimal defconfig
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_BERKELEYDB=y
the current code does not prevent the build of
output/build/python-2.7.6/Modules/_bsddb.o
because the module is really called _bsddb,
see python-2.7.6/Modules/_bsddb.c, line 9604.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The cross-compilation improvements integrated in Python rely on the
compiler exposing a line starting with LIBRARY_PATH when called with
-E -v. This is used by Python setup.py to find the installation
locations of libraries.
However, this LIBRARY_PATH line is not shown by very old compilers,
such as the gcc 4.2.x compiler used on the AVR32 architecture. This
causes libraries installed in the sysroot, such as libffi, to not be
detected by the setup.py script.
To fix this problem, this patch adds addtional logic to setup.py,
which consists in deriving the library paths from the sysroot
location, if no LIBRARY_PATH field was found.
Fixes:
http://autobuild.buildroot.org/results/1aa/1aad2d677dbf7b0a3cb0120a35f45123124f51ab/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This change adds a patch to python disabling the installation of the
python and python-config symlinks.
This allows Buildroot to control these symlinks' installation:
* the python symlink should be unconditionally installed in the target
tree, and the python-config symlink in the staging tree, since it is
only built and installed in the target tree if the user selected it;
* the python and python-config symlinks should only be installed in
the host tree when python(2) is the selection of the user for the
target.
Otherwise, when python3 is selected for the target, the host-python
may be required to built some packages. In such cases, the python
symlink should points to python3 (so should the python-config
symlink) to reflect the staging/target tree.
[Thomas: fix comments according to Yann's suggestions, and replaced
python(2) by python2, as suggested by Yann.]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
During installation, host-python and host-python3 run the freshly built
python executable. This is done with a proper LD_LIBRARY_PATH to make
sure it picks up the libpython in the build directory. However, the
python binary has an RPATH pointing to the $(HOST_DIR)/usr/lib.
Therefore, if libpython exists there, it will be used instead.
If the install step is run in parallel, it is possible that libpython
is already partially copied to $(HOST_DIR)/usr/lib when python is run.
This gives an error like:
python: error while loading shared libraries: $(HOST_DIR)/usr/lib/libpython3.4m.so.1.0: file too short
The fix is simple: use RUNPATH instead of RPATH, which allows
LD_LIBRARY_PATH to override RUNPATH. That way, the libpython in the
build directory is always used. RUNPATH is enabled by passing
--enable-new-dtags to the linker.
Fixes e.g.
http://autobuild.buildroot.net/results/2a6/2a62de3247ba5ad273f03d01e690a3eeb11aa7b4
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The original version uses sysconfig from the python interpreter
(normally host-python) which isn't really suited to provide information
of the target python.
Use the pure shell preprocessed backport from the upcoming python 3.4
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A confusion was made when applying commit
c3d539b53f ('host python/python3:
conditionally disable unicodedata') and then commit
73293e88c8 ('python, python3: enable
unicodedata for host-python, needed by setuptools').
The first commit added the enabling of unicodedata in the host Python
when the target Python is configured with unicodedata, which is
necessary because building the target unicodedata Python module
requires having unicodedata support in the host Python.
The second commit enabled the unicodedata unconditionally in the host
Python, because it is needed by host-setuptools.
However, when the second commit was applied, the logic that consisted
in disabling unicodedate in the host Python when not needed was kept,
which resulted in breaking the build of host-setuptools due to the
lack of unicodedata support in the host python.
This commit fixes that by only leaving the unconditional
--enable-unicodedata in the host Python configuration options, and
therefore removing the problematic conditional --disable-unicodedata.
Fixes:
http://autobuild.buildroot.org/results/b62/b622fc14776f5a6c26ff0d1fb882f4ae6cccc5d8/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As we are going to bump setuptools to a much newer version, the host
python needs to be built with support for unicodedata.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The host python always had --disable-unicodedata, regardless of the
corresponding configuration option BR2_PACKAGE_PYTHON_UNICODEDATA.
Since the host python is used to byte-compile python modules, this meant
that such modules could not contain unicode strings. For example, following
statement in a python module:
print u"\N{SOLIDUS}"
would cause the byte-compilation to fail with message:
SyntaxError: ("(unicode error) \\N escapes not supported (can't load
unicodedata module)",
Instead, conditionally disable unicodedata based on
BR2_PACKAGE_PYTHON_UNICODEDATA, also for the host python.
This fixes bug #6542 (https://bugs.busybox.net/show_bug.cgi?id=6542)
Reported-by: Gernot Vormayr <gvormayr@gmail.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though jumping from 2.7.3 to 2.7.6 looks like a minor version
bump, it is in fact a fairly significant one, because a good number of
changes to help cross-compilation have been merged into Python
upstream. Therefore, most of our patches are affected by this change.
In detail, this commit:
* Renames all the patches to follow the naming convention of patches
in Buildroot: the patch file names should not have any version
number.
* The patches numbered above 100, that add configuration options to
disable certain modules of the Python standard library, are only
renamed and slightly adapted, they didn't change that much.
* The patches numbered below 100 are almost entirely rewritten: many
of the cross-compilation problems that used to exist in Python
2.7.3 no longer exist, and the number of remaining problems is
smaller, and can be fixed with smaller patches.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As a preparation to make the Python infrastructure support both Python
and Python 3, as well as the bump of Python 2 and 3, we need the
Python package to expose the Python module path in a variable called
PYTHON_PATH. It will be used by the following commits.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch is based on the original new pkg patch submitted last Jan
and is part of the "Patchwork oldest patches cleanup #5".
[Peter: fix CONF_OPT indentation]
Signed-off-by: Matt Weber <mlweber1@rockwellcollins.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When a package A depends on config option B and toolchain option C, then
the comment that is given when C is not fulfilled should also depend on B.
For example:
config BR2_PACKAGE_A
depends on BR2_B
depends on BR2_LARGEFILE
depends on BR2_WCHAR
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
This comment should actually be:
comment "A needs a toolchain w/ largefile, wchar"
depends on BR2_B
depends on !BR2_LARGEFILE || !BR2_WCHAR
or if possible (typically when B is a package config option declared in that
same Config.in file):
if BR2_B
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
[other config options depending on B]
endif
Otherwise, the comment would be visible even though the other dependencies
are not met.
This patch adds such missing dependencies, and changes existing such
dependencies from
depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC
to
depends on BR2_BASE_DEP
depends on !BR2_TOOLCHAIN_USES_GLIBC
so that (positive) base dependencies are separate from the (negative)
toolchain dependencies. This strategy makes it easier to write such comments
(because one can simply copy the base dependency from the actual package
config option), but also avoids complex and long boolean expressions.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since 97c687000 (pkg-autotools.mk: default host AUTORECONF{,_OPT} to the
target values) we automatically enable autoreconf for host builds if it
is enabled for the target, so these can go.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: leave change xz tarball format to not end up with circular deps]
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Also move smtpd.py removal to the global remove useless files define.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This finally removes the BR2_HAVE_DEVFILES option, that was used to
install/keep development files on target. With the recent migration of
the internal backend to the package infrastructure, we had anyway lost
the ability to build gcc for the target, and install the uClibc
development files on the target.
[Peter: also remove support/scripts/copy.sh]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We already remove python2.7-config and the symbolic link
python-config, but we forgot to remove the python2-config symbolic
link.
Note that we can't use the <pkg>_CONFIG_SCRIPTS mechanism here because
python2.7-config is written in... Python, and doesn't follow the usual
syntax of <pkg>-config scripts. It takes the paths directly from
distutils.sysconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Bernd Kuhls
Ivan Sergeev
Thomas Petazzoni
Samuel Martin
Arnout Vandecappelle
Gustavo Zacarias
Peter Korsgaard
Przemyslaw Wrzos
Thomas De Schampheleire
Matthew Weber
Jerzy Grzegorek
Alexandre Belloni