NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6e9112f0a4
kumquat-buildroot/support/misc/Buildroot.cmake

8 lines
324 B
CMake
Raw Normal View History

support/cmake: impersonate a Linux system even more Some packages test the system name to decide whether to enable/disable features or link with specific libs. So we forcefully set the system name form our custom system file, so that packagses still believe they are running on Linux rather than Buildroot. Fixes: fastd : http://autobuild.buildroot.net/results/f1d/f1dfe90068ad62e733f17a22202235415bda3974/ paho-mqtt-c: http://autobuild.buildroot.net/results/457/457d76279e16247bf58c838a2c5dd0a4f3962c21/ libiio : http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/ and so on... Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Ben Boeckel <mathstuf@gmail.com> Cc: Jörg Krause <joerg.krause@embedded.rocks> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-02 22:03:15 +01:00
# Impersonate a Linux system. Afterall, that's what we are...
set(CMAKE_SYSTEM_NAME Linux)
core/pkg-cmake: provide our own platform description 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>
2017-02-28 19:07:22 +01:00
include(Platform/Linux)
support/cmake: impersonate a Linux system even more Some packages test the system name to decide whether to enable/disable features or link with specific libs. So we forcefully set the system name form our custom system file, so that packagses still believe they are running on Linux rather than Buildroot. Fixes: fastd : http://autobuild.buildroot.net/results/f1d/f1dfe90068ad62e733f17a22202235415bda3974/ paho-mqtt-c: http://autobuild.buildroot.net/results/457/457d76279e16247bf58c838a2c5dd0a4f3962c21/ libiio : http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/ and so on... Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Ben Boeckel <mathstuf@gmail.com> Cc: Jörg Krause <joerg.krause@embedded.rocks> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-02 22:03:15 +01:00
# Override problematic settings, to avoid RPATH against host lib directories.
core/pkg-cmake: provide our own platform description 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>
2017-02-28 19:07:22 +01:00
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
Reference in New Issue Copy Permalink