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>
I just found out that, that the BUILD_VARIANT var
is not set for the host build, so technically this code
would never get used.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
As both LEDE and OpenWrt have STAGING_DIR_HOSTPKG now, we can start to rely
on it. See 73b7f55424 for more information on
STAGING_DIR_HOSTPKG.
STAGING_DIR_HOSTPKG won't actually be changed before the first LEDE release
(it is equivalent to $(STAGING_DIR)/host), so this simple search/replace
cleanup is safe to apply. Doing this cleanup now will be useful for the
Gluon project (an OpenWrt/LEDE based firmware framework) for experimenting
with modifying STAGING_DIR_HOSTPKG before doing this in the LEDE upstream.
Also fixes a typo in the dbus Makefile ("STAGIND_DIR").
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
STAGING_DIR_HOSTPKG is now defined in both OpenWrt and LEDE, so we can
start to rely on it.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
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>
Most python packages use the same build rules & vars.
So, adding them in python-package.mk.
Also, preparing for using VARIANTs for python/python3 packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
PYTHON_FOR_BUILD is used to build the target python.
Nomally Python scripts detect fine the Python host interpreter
to use for building the Python target interpreter.
But, let's not leave it up to chance anymore.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And apparently `--with-system-ffi` does not take any arguments.
But it's only in Python 3.6 that a check was added for that.
After checking, Python 2.7 does not take any args either
for `--with-system-ffi` ; so, remove it [for the case when this
change may get backported].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Move the python-host.mk and python-package.mk includes after the definition of
common package variables. This is required to ensure that PKG_UNPACK is not set
to to the dummy "true" command which happens if PKG_SOURCE is not yet set.
Fixes the following error observed while attempting to build Python on a recent
LEDE version:
make[2]: Entering directory '.../lang/python'
true
[ ! -d ./src/ ] || cp -fpR ./src/* .../Python-2.7.12
Applying ./patches/001-enable-zlib.patch using plaintext:
can't find file to patch at input line 14
Perhaps you used the wrong -p or --strip option?
[...]
Patch failed! Please fix ./patches/001-enable-zlib.patch!
Makefile:242: recipe for target '.../Python-2.7.12/.prepared_...' failed
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
--sysconfigdir and --sbindir are obtained from --prefix
and --exec-prefix, so no need to have them explicitly
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Allows for more granularity with respect to python-host.mk
and python-package.mk inclusions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
So that it can be included twice.
python-package.mk include python-host.mk, but at some point
in time python-host.mk is not exported to staging_dir yet.
So, to have in python's Makefile, we need to include it
in the Makefile, and to prevent double inclusion (if
python-host.mk is exported from a previous build), the
include guard is added.
Also, moved the includes after some vars were set.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Currently, the python-host.mk framework relies on HOST_BUILD_PREFIX to
refer to the $(STAGING_DIR)/host directory but using the HOST_BUILD_PREFIX
variable requires the use of include/host-build.mk which in turn includes
python-host.mk, leading to target redefinition errors.
In order to provide a global, uniform way to refer to the host staging
directory, LEDE introduced a new variable STAGING_DIR_HOSTPKG which points
to $(STAGING_DIR)/host for now with the purpose of eventually being able to
relocate that directory in the future.
This commit changes python-host.mk to ...
- stop including include/host-build.mk (revert of #3423)
- replace usages of $(HOST_BUILD_PREFIX) with $(STAGING_DIR_HOSTPKG)
- warn and fallback to $(STAGING_DIR)/host if STAGING_DIR_HOSTPKG is
unavailable
The fallback code will ensure that the python host build infrastructure
continues to work properly on older OpenWrt and LEDE versions until the
STAGING_DIR_HOSTPKG is fully settled in and can be removed some time
in the future.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Also, override all prefix args in the HOST_CONFIGURE_ARGS
so that this works fine on CC/15.05.
There are some changes in core regarding package builds that
require this.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
It seems that this can become an issue.
Found when building python3-setuptools from packages/trunk
in openwrt/15.05.
python3-setuptools is not in packages/for-15.05
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The sets host Python's prefix and exec-prefix to the same value
($(STAGING_DIR)/host for packages, as currently defined in
include/host-build.mk), which avoids the case where pyconfig.h is
not in the same location as Python's other header files (see
https://bugs.python.org/issue896330).
This also removes some cross compilation workarounds
(_python_sysroot/prefix/exec_prefix, disabling byte-compilation,
__PYVENV_LAUNCHER__) that are not necessary when compiling packages
for host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
AFAIK sysroot is combined with prefix/exec_prefix, so sysroot shouldn't
include "/usr". (cf. the HostPython function in older versions of
python-package.mk)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This adds code to make it easier to build third-party python
modules such as ones from PyPi.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
Seems those pkgconfig file paths were revealed to be incorrect
after doing a full clean build.
And I only had to inspiration to do one after doing the initial PR.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And split python-dev and python-lib2to3 packages.
Seems for python3 this was done, so we'll sync here.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That means basically moving the host Python from $(STAGING_DIR_HOST)
to $(STAGING_DIR_HOST)/usr and making the PYTHONPATH var
as an argument.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some python packages (e.g. cffi) compile one or more shared libraries
as part of their setup process. When these packages are setup
dependencies of other packages (e.g. cryptography), these packages (and
their shared libraries) will need to be loaded on the host system.
This adds a makefile, similar to python-package.mk, to simplify
installing python packages on the host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Since 94f87dc1, host build of Python depends on expat installed in host
staging directory. However, pyexpat extension fails to build if expat
was not built and installed to staging dir before - adding host build
dependency should fix this.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Build depends must refer to the source package name, not the binary one,
therefore we need to use `bzip2` in order to enforce a build of libbz2.so.
Also make the host python build depend on the bzip2 host build in order to
ensure that host python is built with bzip2 support. We don't need a build
dependency for the target python as this already depends on +libbz2 through
python-light. That package dependency in turn implies a build dependency.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>