buildroot/support/misc, branch 2019.02-op-build

Update for 2019.02

2019-03-04T21:49:56+00:00

Signed-off-by: Peter Korsgaard

infra/pkg-cmake: use an obviously-invalid value for CMAKE_SYSTEM_VERSION

2019-01-16T22:19:09+00:00

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" Cc: Arnout Vandecappelle Cc: Thomas Petazzoni Cc: Samuel Martin Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

package/pkg-cmake: add CMAKE_SYSTEM_VERSION to toolchainfile.cmake

2019-01-12T15:06:51+00:00

Quoting the CMake documentation: 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. Thus, we should also set CMAKE_SYSTEM_VERSION in toolchainfile.cmake. It is supposed to be set to the value of `uname -r` on the target. We don't have that exact value available (unless we build the kernel), but the value of BR2_TOOLCHAIN_HEADERS_AT_LEAST contains the (minimum) version of the kernel it will run on, so it should be OK for all practical purposes. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Cc: Samuel Martin Signed-off-by: Thomas Petazzoni

Update for 2018.11

2018-12-01T22:06:49+00:00

Signed-off-by: Peter Korsgaard

Merge branch 'next'

2018-09-07T11:13:17+00:00

Signed-off-by: Peter Korsgaard

Update for 2018.08

2018-09-06T20:11:06+00:00

Signed-off-by: Peter Korsgaard

support/misc: updating Vagrantfile to ubuntu 18.04

2018-08-13T09:45:48+00:00

This patch updates the vagrant box to ubuntu bionic 64 and switches back to the official ubuntu image cause the issues with the official image are now solved. Signed-off-by: Angelo Compagnucci Signed-off-by: Thomas Petazzoni

support/misc/toolchainfile.cmake.in: use TARGET_LDFLAGS for shared and module libraries

2018-07-19T07:33:37+00:00

With cmake packages, we are only using TARGET_LDFLAGS for executables and not for shared libraries. This patch adds CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS to the cmake toolchain file so that buildroot TARGET_LDFLAGS are used for shared and module libraries. Signed-off-by: Damien Thébault Signed-off-by: Thomas Petazzoni

Update for 2018.05

2018-06-01T20:22:57+00:00

Signed-off-by: Peter Korsgaard

Update for 2018.02

2018-03-04T21:28:34+00:00

Signed-off-by: Peter Korsgaard