[Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description

["Jörg Krause" <joerg.krause@embedded.rocks>]

Hi Yann,

On Tue, 2017-02-28 at 19:07 +0100, Yann E. MORIN wrote:
> 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/fd0ba54c7ab
> f973691b39a0ca1bb4e07d749593a/
> ? - freerdp??: http://autobuild.buildroot.org/results/5d4/5d429d0e288
> 754a541ee5d8be515454c5fccd28b/
> ? - libcec???: http://autobuild.buildroot.org/results/3f3/3f3593bab77
> 34dd274faf5b5690895e9424cbb89/
> ? - 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.

Upstream has opened an issue [1] about this and is already working on a
fix [2] for version 3.7 and 3.8. It fixes the behavior of how
FIND_LIBRARY_USE_LIB32_PATHS handle symlinks.?As 'lib32' is just just a
symlink to 'lib' in Buildroot, 'find_library()' will skip 'lib32' as a
runtime search path and as a consequence 'lib32' will not be used as
rpath anymore.

> 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.

As the issue might be fixed at some point, do we want to keep the
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! :-)

You are welcome!

[1] https://gitlab.kitware.com/cmake/cmake/issues/16682
[2] https://gitlab.kitware.com/cmake/cmake/merge_requests/534

J?rg