Go to file
Yann E. MORIN a54a7e6bbb infra/pkg-cmake: use an obviously-invalid value for CMAKE_SYSTEM_VERSION
In 36568732e4, we expanded toolchain.cmake to also define the value for
CMAKE_SYSTEM_VERSION, as the cmake documentation states that it must be
manually defined when doing cross-compilation [0]:

    When the CMAKE_SYSTEM_NAME variable is set explicitly to enable
    cross compiling then the value of CMAKE_SYSTEM_VERSION must also
    be set explicitly to specify the target system version.

However, the fix in 36568732e4 uses the version of the kernel headers,
assuming that would be the oldest kernel we could run on. Yet, this is
not the case, because glibc (for example) has fallbacks to support
running on kernels older than the headers it was built against.

The cmake official wiki [1] additionally states:

  * CMAKE_SYSTEM_VERSION : optional, version of your target system, not
    used very much.

Folllowed a little bit below, by:

  * CMAKE_TOOLCHAIN_FILE : absolute or relative path to a cmake script
    which sets up all the toolchain related variables mentioned above

    For instance for crosscompiling from Linux to Embedded Linux on PowerPC
    this file could look like this:

        # this one is important
        SET(CMAKE_SYSTEM_NAME Linux)
        #this one not so much
        SET(CMAKE_SYSTEM_VERSION 1)

    [...]

Furthermore, using the kernel headers version can be a bit misleading (as
it really looks like is is the correct version to use when it is not),
while it is obvious that 1 is not really the output of `uname -r` and
thus is definitely not misleading.

Finally, random searches [2] about CMAKE_SYSTEM_VERSION, mostly only
turns up issues related with Windows, Mac-OS, and to a lesser extent,
Android (where it is forcibly set to 1), with issues realted to running
under just Linux (as opposed to Adnroid) mostly non-existent.

Consequently, we revert to using the value that is suggested in the
cmake WiKi, i.e. 1, and which is basically what we also used as a
workaround in the azure-iot-sdk-c paclkage up until d300b1d3b1.

A case were we will need to have a real kernel version, is if we one day
have a cmake-based pacakge that builds and installs a kernel module [3],
because it will need the _running_ kernel version to install it in
/lib/modules/VERSION/, but in that case it will anyway most probably
not be the headers version.

[0] https://cmake.org/cmake/help/v3.8/variable/CMAKE_SYSTEM_VERSION.html
[1] https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling
[2] https://duckduckgo.com/?q=CMAKE_SYSTEM_VERSION
[3] https://stackoverflow.com/questions/38205745/cmake-system-version-not-updated-for-new-kernel

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit fc8a5f56b9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-01-24 16:48:02 +01:00
arch arch/arm: restrict more armv8a cores to aarch64 2019-01-18 15:54:10 +01:00
board board/pc: ensure grub.cfg is copied to target filesystem 2019-01-23 16:17:38 +01:00
boot boot/grub: fix grub-mkimage with binutils >= 2.31 2018-12-16 22:26:47 +01:00
configs board/pc: ensure grub.cfg is copied to target filesystem 2019-01-23 16:17:38 +01:00
docs Makefile, manual, website: Bump copyright year 2019-01-24 12:26:19 +01:00
fs fs/tar: add support for xattrs (thus capabilties) 2018-11-20 23:28:07 +01:00
linux {linux, linux-headers}: bump 4.{9, 14, 19, 20}.x series 2019-01-24 16:04:13 +01:00
package infra/pkg-cmake: use an obviously-invalid value for CMAKE_SYSTEM_VERSION 2019-01-24 16:48:02 +01:00
support infra/pkg-cmake: use an obviously-invalid value for CMAKE_SYSTEM_VERSION 2019-01-24 16:48:02 +01:00
system package/systemd: needs glibc 2018-11-22 17:15:33 +01:00
toolchain toolchain: CodeSourcery AMD64 affected by PR20006 2018-11-29 21:22:18 +01:00
utils utils/get-developers: really make it callable from elsewhere than the toplevel directory 2019-01-24 11:58:30 +01:00
.defconfig arch: remove support for sh64 2016-09-08 22:15:15 +02:00
.flake8 .flake8: ignore utils/diffconfig 2018-03-13 22:37:54 +01:00
.gitignore update gitignore 2013-05-04 12:41:55 +02:00
.gitlab-ci.yml .gitlab-ci.yml: update after addition of TestF2FS test case 2018-11-08 22:41:53 +01:00
.gitlab-ci.yml.in .gitlab-ci.yml: do runtime tests only on explicit trigger 2018-10-21 23:34:18 +02:00
CHANGES Update for 2018.11.1 2018-12-19 23:04:07 +01:00
Config.in Config.in: security hardening: disable FORTIFY_SOURCE for gcc < 6 2018-11-06 08:54:25 +01:00
Config.in.legacy package/docker-engine: split docker-{cli, engine}, bump to v18.09.0 2018-12-16 15:11:29 +01:00
COPYING COPYING: add exception about patch licensing 2016-02-26 19:50:13 +01:00
DEVELOPERS DEVELOPERS: remove Sebastien Bourdelin 2019-01-18 15:53:19 +01:00
Makefile Makefile, manual, website: Bump copyright year 2019-01-24 12:26:19 +01:00
Makefile.legacy Remove BR2_DEPRECATED 2016-10-15 23:14:45 +02:00
README README: add reference to submitting-patches 2016-02-01 19:16:08 +01:00

Buildroot is a simple, efficient and easy-to-use tool to generate embedded
Linux systems through cross-compilation.

The documentation can be found in docs/manual. You can generate a text
document with 'make manual-text' and read output/docs/manual/manual.text.
Online documentation can be found at http://buildroot.org/docs.html

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the target architecture and the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) find the kernel, bootloader, root filesystem, etc. in output/images

You do not need to be root to build or run buildroot.  Have fun!

Buildroot comes with a basic configuration for a number of boards. Run
'make list-defconfigs' to view the list of provided configurations.

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org
You can also find us on #buildroot on Freenode IRC.

If you would like to contribute patches, please read
https://buildroot.org/manual.html#submitting-patches