The libc-compat.h first appeared in kernel version 3.12. Trying to build a
musl toolchain using earlier headers leads to the following failure:
/bin/sed: can't read .../output/host/usr/arm-buildroot-linux-musleabi/sysroot/usr/include/linux/libc-compat.h: No such file or directory
package/pkg-generic.mk:266: recipe for target '.../output/build/toolchain/.stamp_staging_installed' failed
Don't apply the sed patch to older headers.
Reported-by: Florent Jacquet <florent.jacquet@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The handling of RPATH in cmake-3.7 has changed drastically, causing a
slew of build failures dues to libraries from the host being pulled in:
- domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7abf973691b39a0ca1bb4e07d749593a/
- freerdp : http://autobuild.buildroot.org/results/5d4/5d429d0e288754a541ee5d8be515454c5fccd28b/
- libcec : http://autobuild.buildroot.org/results/3f3/3f3593bab7734dd274faf5b5690895e9424cbb89/
- and so on...
The bug was reported upstream [0], which dismissed it altogether [1] as
being expected behaviour, quoting:
I don't think there is anything wrong with that change on its own.
It merely exposed some existing behavior in a new case.
Instead, upstream suggested in that same message that a platform
definition be used instead, quoting:
If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
`Platform/MySystem.cmake` file is loaded then the latter can set
them as needed for the target platform.
So here we are doing so:
- we add a new platfom definitions that inherits from the Linux one,
then overrides the problematic settings;
- we change our toolchain file to use that platform instead;
- we tell cmake where to find additional modules, so that it can find
our custom platform file.
This has been tested to work in the following conditions:
- pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
(manually built)
- internal cmake, versions 3.6.3 (the current version as of this
patch) and 3.7.2 (with the followup patches).
Thanks to Jörg, Ben and Baruch for the help investigating the issue.
Special thanks to Jörg for handling the discussion with upstream and
pointing to the relevant messages! :-)
[0] http://public.kitware.com/pipermail/cmake/2017-February/064970.html
[1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
To be noted: Thomas suggested we set these directly in the toolchain
file. Unfortunately, wherever we put those settings in the toolchain
file, this does not work.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Rick Felker suggested[1] this hack as a workaround to musl libc conflict with
kernel headers:
The problem is linux/libc-compat.h, which should fix this, only works
on glibc, by design. See:
#ifndef _LIBC_COMPAT_H
#define _LIBC_COMPAT_H
/* We have included glibc headers... */
#if defined(__GLIBC__)
/* Coordinate with glibc netinet/in.h header. */
#if defined(_NETINET_IN_H)
If you patch it like this:
-#if defined(__GLIBC__)
+#if 1
then it should mostly work but it's still all a big hack. I think
that's what distros are doing. The problem is that the same header is
trying to do two different things:
1. Provide extra linux-kernel-API stuff that's not in the
libc/userspace headers.
2. Provide definitions of the standard types and constants for uClibc
and klibc, which don't have complete libc headers and rely on the
kernel headers for definitions.
These two uses really should be separated out into separate headers so
that the latter only get included explicitly by uClibc and klibc and
otherwise remain completely unused. But that would require coordinated
changes/upgrades which are unlikely to happen. :(
Upstream musl still evaluates[2][3] a permanent solution.
With this in place we can revert (at least) commits a167081c5d (bridge-utils:
fix build with musl) and e74d4fc493 (norm: add patch to fix musl build).
[1] http://www.openwall.com/lists/musl/2015/10/08/2
[2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
[3] http://www.openwall.com/lists/musl/2016/11/09/2
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch migrates the toolchain and toolchain-buildroot packages to the
virtual package infrastructure, causing the log messages to change from:
>>> toolchain undefined Downloading
>>> toolchain undefined Extracting
...
to
>>> toolchain virtual Downloading
>>> toolchain virtual Extracting
...
and similar for 'toolchain-buildroot', simply because it looks nicer.
At the same time, the directory names also become toolchain-virtual,
toolchain-buildroot-virtual instead of the corresponding 'undefined'
variants.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit makes the dependency from the target toolchain explicit.
This way we can buid from command line a package that use
inner-generic-package right after the configuration phase, example:
make clean <package-name>
Also remove TARGETS_ALL because the only purpose was to add toolchain
dependency so it's superseded by this commit.
To prevent circular dependency add the new variable
<pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain
dependency for toolchain packages.
This is also a step forward supporting top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Move "dependencies" "dirs" "prepare" dependencies from "toolchain" to
every package.
This way we can build correctly every package right after the clean
stage.
As example with this commit we can build successfully the glibc right
after the clean stage:
make clean glibc
This is also a step forward supporting top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit introduces a virtual package called 'toolchain', located
in 'toolchain/toolchain', which simply depends on
'toolchain-buildroot' or 'toolchain-external' depending on the
selected toolchain backend.
For now, toolchain-buildroot and toolchain-external are still manual
make targets, but the following patches convert those backends to use
the package infrastructure as well.
In addition to this:
* The main Makefile is modified to always make BASE_TARGETS point to
this new toolchain virtual package.
* The main Makefile is changed to include all the toolchain/*/*.mk
files: the toolchain virtual package, and the toolchain-buildroot
and toolchain-external directories.
* The dependency of the toolchain on prepare dirs and dependencies is
moved to the toolchain virtual package. It is moved as a
prerequisite of the "toolchain-source" rule to ensure that all
directories are prepared before we even start extracting the
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
