package/cmake: re-introduce cmake-3.7

PATCH New Yann E. MORIN 5 participants 26 messages Feb 28, 2017 – Mar 6, 2017

lore

Share & tools

lore

Yann E. MORIN

author

2017-02-28 18:07 UTC #0 lore raw

cover package/cmake: re-introduce cmake-3.7

Hello All!

This series re-introduces cmake-3.7, along with a way to fix the RPATH issue in this release, and slated to stay upstream as-is.

We define a new platform that gets rid of the offending settings. See the first commit log for the nitty-gritty details. This works for all versions of cmake, so is safe to do before re-introducing cmake-3.7.

Once we have this support, we can bump cmake again. We reuse the four original patches, to keep authoorship (although they could well all be squashed into one).

Regards,
Yann E. MORIN.

The following changes since commit 1c186c6ca1689111fb2a4a164f57b3b96ebd21c8

qt5quickcontrols: fix installation of PrivateWidgets (2017-02-28 15:55:29 +0100)

are available in the git repository at:

git://git.buildroot.org/~ymorin/git/buildroot.git

for you to fetch changes up to a97614e367871d75a4e109b7d45a6dd48fb9fe19

cmake: bump version to 3.7.2 (2017-02-28 19:00:20 +0100)

----------------------------------------------------------------
Thomas Petazzoni (1):
cmake: adjust dependencies added for libuv

Vicente Olivert Riera (3):
cmake: bump version to 3.7.0
cmake: bump version to 3.7.1
cmake: bump version to 3.7.2

Yann E. MORIN (1):
core/pkg-cmake: provide our own platform description

 package/cmake/Config.in             | 9 +++++++--
 package/cmake/cmake.hash            | 4 ++--
 package/cmake/cmake.mk              | 6 +++---
 package/pkg-cmake.mk                | 4 ++++
 support/misc/Buildroot.cmake        | 3 +++
 support/misc/toolchainfile.cmake.in | 2 +-
 toolchain/toolchain/toolchain.mk    | 1 +
 7 files changed, 21 insertions(+), 8 deletions(-)
 create mode 100644 support/misc/Buildroot.cmake

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Yann E. MORIN

author

2017-02-28 18:07 UTC #1 lore raw

PATCH 1/5 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" <[email protected]>

Cc J?rg Krause <[email protected]>

Cc Ben Boeckel <[email protected]>

Cc Baruch Siach <[email protected]>

Cc Samuel Martin <[email protected]>

Cc Vicente Olivert Riera <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Peter Korsgaard <[email protected]>

---
 package/pkg-cmake.mk                | 4 ++++
 support/misc/Buildroot.cmake        | 3 +++
 support/misc/toolchainfile.cmake.in | 2 +-
 toolchain/toolchain/toolchain.mk    | 1 +
 4 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 support/misc/Buildroot.cmake

package/pkg-cmake.mk +4 -0

index a7c8dc3..77fa1dc 100644
@@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
 	PATH=$$(BR_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
+		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \
 		-DCMAKE_INSTALL_PREFIX="/usr" \
 		-DCMAKE_COLOR_MAKEFILE=OFF \
 		-DBUILD_DOC=OFF \

@@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
 		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
 		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
 		> $@
+
+$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
+	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)

support/misc/Buildroot.cmake new file +3 -0

new file mode 100644
index 0000000..b0046b3
@@ -0,0 +1,3 @@
+include(Platform/Linux)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)

support/misc/toolchainfile.cmake.in +1 -1

index d4252dd..5a42644 100644
@@ -10,7 +10,7 @@
 # RELOCATED_HOST_DIR variable.
 string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
 
-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
 
 # Set the {C,CXX}FLAGS appended by CMake depending on the build type

toolchain/toolchain/toolchain.mk +1 -0

index b16db01..e298373 100644
@@ -38,3 +38,4 @@ endif
 $(eval $(virtual-package))
 
 toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
+toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake

Signature · 1 line

2.7.4

Baruch Siach

2017-02-28 18:26 UTC #2 lore raw

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

Hi Yann,

Quoted 25 lines · Yann E. MORIN

package/pkg-cmake.mk +4 -0

index a7c8dc3..77fa1dc 100644
@@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
 	PATH=$$(BR_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
+		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \
 		-DCMAKE_INSTALL_PREFIX="/usr" \
 		-DCMAKE_COLOR_MAKEFILE=OFF \
 		-DBUILD_DOC=OFF \

@@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
 		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
 		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
 		> $@
+
+$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
+	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)

support/misc/Buildroot.cmake new file +0 -0

new file mode 100644
index 0000000..b0046b3

support/misc/Buildroot.cmake line 1

Quoted 1 line

support/misc/Buildroot.cmake new file +1 -0
@@ -0,0 +1,3 @@
+include(Platform/Linux)

So this goes to the host directory in case of host installed cmake? What happens when the host installed cmake is older than 3.1? Does the Buildroot built module path override the host installed one?

baruch

Quoted 24 lines

support/misc/Buildroot.cmake new file +2 -0

+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)

support/misc/toolchainfile.cmake.in +1 -1

index d4252dd..5a42644 100644
@@ -10,7 +10,7 @@
 # RELOCATED_HOST_DIR variable.
 string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
 
-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
 
 # Set the {C,CXX}FLAGS appended by CMake depending on the build type

toolchain/toolchain/toolchain.mk +1 -0

index b16db01..e298373 100644
@@ -38,3 +38,4 @@ endif
 $(eval $(virtual-package))
 
 toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
+toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake

Signature · 3 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Yann E. MORIN

author

2017-02-28 20:03 UTC #3 lore raw

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

Baruch, All,

On 2017-02-28 20:26 +0200, Baruch Siach spake thusly:

Quoted 23 lines · Yann E. MORIN

Quoted 22 lines

package/pkg-cmake.mk +4 -0

index a7c8dc3..77fa1dc 100644
@@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
 	PATH=$$(BR_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
+		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \
 		-DCMAKE_INSTALL_PREFIX="/usr" \
 		-DCMAKE_COLOR_MAKEFILE=OFF \
 		-DBUILD_DOC=OFF \

@@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
 		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
 		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
 		> $@
+
+$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
+	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)

support/misc/Buildroot.cmake new file +0 -0

new file mode 100644
index 0000000..b0046b3

Quoted 8 lines

support/misc/Buildroot.cmake line 1
Quoted 4 lines
support/misc/Buildroot.cmake new file +1 -0
@@ -0,0 +1,3 @@
+include(Platform/Linux)
So this goes to the host directory in case of host installed cmake? What happens when the host installed cmake is older than 3.1? Does the Buildroot built module path override the host installed one?

When the host cmake is older than 3.1, we build and use our own cmake.

And the modules path we provide is looked for first, then cmake uses the builtin one:
https://cmake.org/cmake/help/v3.0/variable/CMAKE_MODULE_PATH.html

I should have written that in the commit log, indeed.

Regards,
Yann E. MORIN.

Quoted 31 lines

baruch

Quoted 24 lines

support/misc/Buildroot.cmake new file +2 -0

+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)

support/misc/toolchainfile.cmake.in +1 -1

index d4252dd..5a42644 100644
@@ -10,7 +10,7 @@
 # RELOCATED_HOST_DIR variable.
 string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
 
-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
 
 # Set the {C,CXX}FLAGS appended by CMake depending on the build type

toolchain/toolchain/toolchain.mk +1 -0

index b16db01..e298373 100644
@@ -38,3 +38,4 @@ endif
 $(eval $(virtual-package))
 
 toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
+toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake

Signature · 3 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Jörg Krause

2017-02-28 20:41 UTC #4 lore raw

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

In reply to Yann E. MORIN

Hi Yann,

Quoted 20 lines · Yann E. MORIN

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.

Quoted 7 lines

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.

Quoted 11 lines

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?

Quoted 11 lines

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

Yann E. MORIN

author

2017-02-28 20:58 UTC #5 lore raw

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

J?rg, All,

On 2017-02-28 21:41 +0100, J?rg Krause spake thusly:

Quoted 42 lines · Yann E. MORIN

Quoted 20 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
So here we are doing so:
? - we add a new platfom definitions that inherits from the Linux one,
????then overrides the problematic settings;

Quoted 8 lines

Quoted 5 lines
? - 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?

Well, what bad would it do to have our own platform file? We could even use it for yet more options if need be.

And in the meantime, there is no release of cmake with a fix. I'll believe they've fixed it when I see it! ;-)

Regards,
Yann E. MORIN.

Quoted 18 lines

Quoted 11 lines
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

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Jörg Krause

2017-02-28 22:15 UTC #6 lore raw

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

Hi Yann,

Quoted 63 lines · Yann E. MORIN

J?rg, All,
On 2017-02-28 21:41 +0100, J?rg Krause spake thusly:
Quoted 60 lines · Yann E. MORIN
Quoted 26 lines
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/fd0ba54
c7ab
f973691b39a0ca1bb4e07d749593a/
? - freerdp??: http://autobuild.buildroot.org/results/5d4/5d429d0
e288
754a541ee5d8be515454c5fccd28b/
? - libcec???: http://autobuild.buildroot.org/results/3f3/3f3593b
ab77
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.
Quoted 8 lines
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.
Quoted 12 lines
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.

Quoted 6 lines

Quoted 2 lines
As the issue might be fixed at some point, do we want to keep the custom platform file?
Well, what bad would it do to have our own platform file? We could even
use it for yet more options if need be.

No offense. There is nothing wrong about having a custom buildroot platform file.

Quoted 2 lines

And in the meantime, there is no release of cmake with a fix. I'll believe they've fixed it when I see it! ;-)

:-)

J?rg

Arnout Vandecappelle

2017-03-01 08:01 UTC #7 lore raw

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

In reply to Yann E. MORIN

Quoted 51 lines · Yann E. MORIN

J?rg, All,
On 2017-02-28 21:41 +0100, J?rg Krause spake thusly:
Quoted 48 lines · Yann E. MORIN
Quoted 20 lines
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.
Quoted 7 lines
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.
Quoted 11 lines
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.

Quoted 8 lines

Quoted 2 lines
As the issue might be fixed at some point, do we want to keep the custom platform file?
Well, what bad would it do to have our own platform file? We could even use it for yet more options if need be.
And in the meantime, there is no release of cmake with a fix. I'll believe they've fixed it when I see it! ;-)

Also, we want to support existing distro CMake, which doesn't have this fix.

Which reminds me: don't forget to revert
4422eca2d4 dependencies/cmake: blacklist cmake 3.7

Regards,
Arnout

[snip]

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Arnout Vandecappelle

2017-03-01 07:58 UTC #8 lore raw

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

In reply to Yann E. MORIN

Quoted 2 lines · Yann E. MORIN

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:

[snip]

Quoted 2 lines

- we add a new platfom definitions that inherits from the Linux one,
    then overrides the problematic settings;

Not mentioned in the commit log but important to note: this platform file is
only used for target CMake packages, not host packages.

[snip]

package/pkg-cmake.mk define $(2)_CONFIGURE_CMDS · line 90

Quoted 9 lines

package/pkg-cmake.mk +1 -0

index a7c8dc3..77fa1dc 100644
@@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
 	PATH=$$(BR_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
+		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \

Since you don't do any processing on the file, you could just use

		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \

and avoid copying the file around. Of course, in that case, support/cmake is probably a better place to put the file :-)

On the other hand, in the future we may want to add other stuff to the cmake
module path, and that stuff might get processed. I don't really like adding complexity for some unknown future use, but it does make some kind of sense.

If you do copy the file, it should IMHO go into STAGING_DIR, not HOST_DIR. I
think the location of toolchainfile.cmake is incorrect as well. We briefly discussed this at some BR developer meeting IIRC but nobody took action on it.

Regards,
Arnout

Quoted 42 lines

package/pkg-cmake.mk +3 -0

 		-DCMAKE_INSTALL_PREFIX="/usr" \
 		-DCMAKE_COLOR_MAKEFILE=OFF \
 		-DBUILD_DOC=OFF \

@@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
 		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
 		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
 		> $@
+
+$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
+	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)

support/misc/Buildroot.cmake new file +3 -0

new file mode 100644
index 0000000..b0046b3
@@ -0,0 +1,3 @@
+include(Platform/Linux)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)

support/misc/toolchainfile.cmake.in +1 -1

index d4252dd..5a42644 100644
@@ -10,7 +10,7 @@
 # RELOCATED_HOST_DIR variable.
 string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
 
-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
 
 # Set the {C,CXX}FLAGS appended by CMake depending on the build type

toolchain/toolchain/toolchain.mk +1 -0

index b16db01..e298373 100644
@@ -38,3 +38,4 @@ endif
 $(eval $(virtual-package))
 
 toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
+toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Thomas Petazzoni

2017-03-01 08:17 UTC #9 lore raw

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

Hello,

Quoted 3 lines · Arnout Vandecappelle

Since you don't do any processing on the file, you could just use
		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \

I think the idea is that since the Buildroot.cmake platform files gets referenced by the toolchainfile.cmake, then Buildroot.cmake anyway needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can just as well point CMake to this place.

Quoted 2 lines

and avoid copying the file around. Of course, in that case, support/cmake is probably a better place to put the file :-)

No: copying the file is needed, otherwise our toolchainfile.cmake file no longer works for people using it outside of Buildroot.

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Arnout Vandecappelle

2017-03-01 08:35 UTC #10 lore raw

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

Quoted 13 lines · Thomas Petazzoni

Hello,
Quoted 3 lines · Arnout Vandecappelle
Since you don't do any processing on the file, you could just use
		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
I think the idea is that since the Buildroot.cmake platform files gets referenced by the toolchainfile.cmake, then Buildroot.cmake anyway needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can just as well point CMake to this place.

Quoted 5 lines

Quoted 2 lines
and avoid copying the file around. Of course, in that case, support/cmake is probably a better place to put the file :-)
No: copying the file is needed, otherwise our toolchainfile.cmake file no longer works for people using it outside of Buildroot.

Good point. I still think it should be in staging rather than host, but for
sure it's more important to keep them together.

Therefore:

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Regards,
Arnout

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Yann E. MORIN

author

2017-03-01 18:43 UTC #11 lore raw

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

Arnout, All,

On 2017-03-01 09:35 +0100, Arnout Vandecappelle spake thusly:

Quoted 14 lines · Thomas Petazzoni

Quoted 13 lines
Hello,
Quoted 3 lines · Arnout Vandecappelle
Since you don't do any processing on the file, you could just use
		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
I think the idea is that since the Buildroot.cmake platform files gets referenced by the toolchainfile.cmake, then Buildroot.cmake anyway needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can just as well point CMake to this place.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
and avoid copying the file around. Of course, in that case, support/cmake is probably a better place to put the file :-)
No: copying the file is needed, otherwise our toolchainfile.cmake file no longer works for people using it outside of Buildroot.
Good point. I still think it should be in staging rather than host, but for
sure it's more important to keep them together.

Why would you want it in staging? When we build our own internal cmake, the moduels it installs are so installed in host, not staging. They are build-description files, not target files.

Ergo, they should be in host, not staging.

Regards,
Yann E. MORIN.

Quoted 14 lines

Therefore:

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Regards,
Arnout

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Arnout Vandecappelle

2017-03-05 23:27 UTC #12 lore raw

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

Quoted 23 lines · Yann E. MORIN

Arnout, All,
On 2017-03-01 09:35 +0100, Arnout Vandecappelle spake thusly:
Quoted 20 lines · Thomas Petazzoni
Quoted 18 lines
Hello,
Quoted 3 lines · Arnout Vandecappelle
Since you don't do any processing on the file, you could just use
		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
I think the idea is that since the Buildroot.cmake platform files gets referenced by the toolchainfile.cmake, then Buildroot.cmake anyway needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can just as well point CMake to this place.
Quoted 2 lines
and avoid copying the file around. Of course, in that case, support/cmake is probably a better place to put the file :-)
No: copying the file is needed, otherwise our toolchainfile.cmake file no longer works for people using it outside of Buildroot.

Quoted 8 lines

Quoted 2 lines
Good point. I still think it should be in staging rather than host, but for
sure it's more important to keep them together.
Why would you want it in staging? When we build our own internal cmake, the moduels it installs are so installed in host, not staging. They are build-description files, not target files.
Ergo, they should be in host, not staging.

I was looking at it like the .pc files, which are in staging because they talk
about the target.

About the modules: in fact, packages that install .cmake files will do that in
staging, not in host. So I do hope that cmake looks for them in staging as well... That's what CMAKE_FIND_ROOT_PATH is for, isn't it?

In fact, the only .cmake files I see installed in the host dir are:

- the Modules from CMake itself, but these are more related to the CMake language, e.g. CheckIncludeFiles.cmake;

- the CMake files added by *host* packages;

- the CMake files added by buildroot which talk about *target* packages.

So I stand by my original statement: I think the cmake files should move from
HOST/usr/share/buildroot to STAGING/usr/lib/cmake.

Adding Samuel and Luca, our CMake "experts", to Cc.

Regards,
Arnout

Quoted 19 lines

Regards,
Yann E. MORIN.

Quoted 14 lines

Therefore:

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Regards,
Arnout

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Yann E. MORIN

author

2017-03-06 17:00 UTC #13 lore raw

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

Arnout, All,

On 2017-03-06 00:27 +0100, Arnout Vandecappelle spake thusly:

Quoted 27 lines · Yann E. MORIN

Quoted 26 lines
Arnout, All,
On 2017-03-01 09:35 +0100, Arnout Vandecappelle spake thusly:
Quoted 22 lines · Thomas Petazzoni
Quoted 13 lines
Hello,
Quoted 3 lines · Arnout Vandecappelle
Since you don't do any processing on the file, you could just use
		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
I think the idea is that since the Buildroot.cmake platform files gets referenced by the toolchainfile.cmake, then Buildroot.cmake anyway needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can just as well point CMake to this place.
Quoted 5 lines
Quoted 2 lines
and avoid copying the file around. Of course, in that case, support/cmake is probably a better place to put the file :-)
No: copying the file is needed, otherwise our toolchainfile.cmake file no longer works for people using it outside of Buildroot.
Good point. I still think it should be in staging rather than host, but for
sure it's more important to keep them together.

Quoted 8 lines

Quoted 5 lines
Why would you want it in staging? When we build our own internal cmake, the moduels it installs are so installed in host, not staging. They are build-description files, not target files.
Ergo, they should be in host, not staging.
I was looking at it like the .pc files, which are in staging because they talk
about the target.

But it is not like a .pc file. It does not describe libs to link with (-l), or where to lok for headers and libs (-I and -L).

It is more like the toolchain file itself; but see below...

Quoted 8 lines

About the modules: in fact, packages that install .cmake files will do that in
staging, not in host. So I do hope that cmake looks for them in staging as well... That's what CMAKE_FIND_ROOT_PATH is for, isn't it?
In fact, the only .cmake files I see installed in the host dir are:
- the Modules from CMake itself, but these are more related to the CMake language, e.g. CheckIncludeFiles.cmake;

And what about all the modules describing platforms:

host/usr/share/cmake-3.7/Modules/Platform/

and the file that actually sources the platform description:

host/usr/share/cmake-3.7/Modules/CMakeSystemSpecificInformation.cmake

Quoted 6 lines

- the CMake files added by *host* packages;
- the CMake files added by buildroot which talk about *target* packages.
So I stand by my original statement: I think the cmake files should move from
HOST/usr/share/buildroot to STAGING/usr/lib/cmake.

Still not convinced... ;-)

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Arnout Vandecappelle

2017-03-06 22:02 UTC #14 lore raw

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

Quoted 4 lines · Yann E. MORIN

Arnout, All,
On 2017-03-06 00:27 +0100, Arnout Vandecappelle spake thusly:
Quoted 1 line · Yann E. MORIN

[snip]

Quoted 11 lines

Quoted 8 lines
Quoted 5 lines
Why would you want it in staging? When we build our own internal cmake, the moduels it installs are so installed in host, not staging. They are build-description files, not target files.
Ergo, they should be in host, not staging.
I was looking at it like the .pc files, which are in staging because they talk
about the target.
But it is not like a .pc file. It does not describe libs to link with (-l), or where to lok for headers and libs (-I and -L).

How is the specification of the sysroot different from the path to headers and
libs?

Quoted 1 line

It is more like the toolchain file itself; but see below...

If with the toolchain file you mean toolchainfile.cmake, that's exactly my
point: I think toolchainfile.cmake should be in staging.

Quoted 4 lines

Quoted 4 lines
About the modules: in fact, packages that install .cmake files will do that in
staging, not in host. So I do hope that cmake looks for them in staging as well... That's what CMAKE_FIND_ROOT_PATH is for, isn't it?

Quoted 8 lines

Quoted 4 lines
In fact, the only .cmake files I see installed in the host dir are:
- the Modules from CMake itself, but these are more related to the CMake language, e.g. CheckIncludeFiles.cmake;
And what about all the modules describing platforms:
host/usr/share/cmake-3.7/Modules/Platform/

They are not directly related to the target. They contain all the possible
platforms.

Quoted 3 lines

and the file that actually sources the platform description:
host/usr/share/cmake-3.7/Modules/CMakeSystemSpecificInformation.cmake

Note that there is nothing system specific in this file :-)

Anyway, enough bikeshedding, let's just keep things as they are.

Regards,
Arnout

Quoted 13 lines

Quoted 7 lines
- the CMake files added by *host* packages;
- the CMake files added by buildroot which talk about *target* packages.
So I stand by my original statement: I think the cmake files should move from
HOST/usr/share/buildroot to STAGING/usr/lib/cmake.
Still not convinced... ;-)
Regards,
Yann E. MORIN.

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Baruch Siach

2017-03-02 12:29 UTC #15 lore raw

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

In reply to Yann E. MORIN

Hi Yann,

support/misc/toolchainfile.cmake.in line 14

Quoted 3 lines · Yann E. MORIN

support/misc/toolchainfile.cmake.in +1 -1

-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)

This breaks libiio.

http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/

/home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c: In function 'local_open':
/home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c:856:33: error: 'O_CLOEXEC' undeclared (first use in this function)

That is because the libiio CMakeLists.txt has the following code:

IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")

		[...]

        set(CMAKE_REQUIRED_DEFINITIONS "-D_GNU_SOURCE=1")
        add_definitions(-D_GNU_SOURCE=1)

endif()

Now cmake skips this code, thus omitting _GNU_SOURCE which leads to the build failure.

baruch

Signature · 3 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Thomas Petazzoni

2017-03-02 12:41 UTC #16 lore raw

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

Hello,

Quoted 16 lines · Baruch Siach

support/misc/toolchainfile.cmake.in line 14
Quoted 3 lines · Yann E. MORIN
support/misc/toolchainfile.cmake.in +1 -1
-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)  
This breaks libiio.
http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/
/home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c: In function 'local_open':
/home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c:856:33: error: 'O_CLOEXEC' undeclared (first use in this function)
That is because the libiio CMakeLists.txt has the following code:
IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")

Quoted 8 lines

		[...]

        set(CMAKE_REQUIRED_DEFINITIONS "-D_GNU_SOURCE=1")
        add_definitions(-D_GNU_SOURCE=1)
endif()
Now cmake skips this code, thus omitting _GNU_SOURCE which leads to the build failure.

As I reported earlier today, this series breaks several other CMake based packages. So I guess, we're good for yet another revert, back to CMake 3.6.

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Yann E. MORIN

author

2017-02-28 18:07 UTC #17 lore raw

PATCH 2/5 cmake: bump version to 3.7.0

In reply to Yann E. MORIN

From: Vicente Olivert Riera <[email protected]>

libuv is now a required dependency.

Signed-off-by Vicente Olivert Riera <[email protected]>

Tested-by Samuel Martin <[email protected]>

Signed-off-by Thomas Petazzoni <[email protected]>

---
 package/cmake/Config.in  | 9 +++++++--
 package/cmake/cmake.hash | 4 ++--
 package/cmake/cmake.mk   | 6 +++---
 3 files changed, 12 insertions(+), 7 deletions(-)

package/cmake/Config.in +7 -2

index 6f04a4a..716d80e 100644
@@ -20,11 +20,14 @@ config BR2_PACKAGE_CMAKE_CTEST
 	select BR2_PACKAGE_EXPAT
 	select BR2_PACKAGE_BZIP2
 	select BR2_PACKAGE_XZ
+	select BR2_PACKAGE_LIBUV
 	depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # from jsoncpp
 	depends on BR2_USE_WCHAR # libarchive
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on !BR2_STATIC_LIBS
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libuv
+	depends on BR2_USE_MMU # libuv
 	help
 	  CTest is a testing tool distributed as a part of CMake. It
 	  can be used to automate updating (using CVS for example),

@@ -34,7 +37,9 @@ config BR2_PACKAGE_CMAKE_CTEST
 
 	  http://www.cmake.org/
 
-comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7"
+comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, threads"
 	depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
+	depends on BR2_USE_MMU
 	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
-		BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
+		BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 || \
+		!BR2_TOOLCHAIN_HAS_THREADS

package/cmake/cmake.hash +2 -2

index f846dc9..687e5a4 100644
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.6/cmake-3.6.3-SHA-256.txt
-sha256 7d73ee4fae572eb2d7cd3feb48971aea903bb30a20ea5ae8b4da826d8ccad5fe  cmake-3.6.3.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.0-SHA-256.txt
+sha256 ed63e05c41aeb6c036e503114ab15847f29c312f9f21f5f1a7060a4b4ec2fb31  cmake-3.7.0.tar.gz

package/cmake/cmake.mk +3 -3

index bc55509..e4904fc 100644
@@ -4,8 +4,8 @@
 #
 ################################################################################
 
-CMAKE_VERSION_MAJOR = 3.6
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3
+CMAKE_VERSION_MAJOR = 3.7
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).0
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3c
 CMAKE_LICENSE_FILES = Copyright.txt

@@ -22,7 +22,7 @@ CMAKE_LICENSE_FILES = Copyright.txt
 #   the system-wide libraries instead of rebuilding and statically
 #   linking with the ones bundled into the CMake sources.
 
-CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz
+CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz libuv
 
 CMAKE_CONF_OPTS = \
 	-DKWSYS_LFS_WORKS=TRUE \

Signature · 1 line

2.7.4

Yann E. MORIN

author

2017-02-28 18:07 UTC #18 lore raw

PATCH 3/5 cmake: bump version to 3.7.1

In reply to Yann E. MORIN

From: Vicente Olivert Riera <[email protected]>

Signed-off-by Vicente Olivert Riera <[email protected]>

Signed-off-by Peter Korsgaard <[email protected]>

---
 package/cmake/cmake.hash | 4 ++--
 package/cmake/cmake.mk   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

package/cmake/cmake.hash +2 -2

index 687e5a4..7a22f21 100644
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.7/cmake-3.7.0-SHA-256.txt
-sha256 ed63e05c41aeb6c036e503114ab15847f29c312f9f21f5f1a7060a4b4ec2fb31  cmake-3.7.0.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.1-SHA-256.txt
+sha256 449a5bce64dbd4d5b9517ebd1a1248ed197add6ad27934478976fd5f1f9330e1  cmake-3.7.1.tar.gz

package/cmake/cmake.mk +1 -1

index e4904fc..107715c 100644
@@ -5,7 +5,7 @@
 ################################################################################
 
 CMAKE_VERSION_MAJOR = 3.7
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).0
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).1
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3c
 CMAKE_LICENSE_FILES = Copyright.txt

Signature · 1 line

2.7.4

Yann E. MORIN

author

2017-02-28 18:07 UTC #19 lore raw

PATCH 4/5 cmake: adjust dependencies added for libuv

In reply to Yann E. MORIN

From: Thomas Petazzoni <[email protected]>

Commit 1ffcf364b6e9894a876dc581a090f87685945412 updated cmake to 3.7.0, which requires selecting the libuv package. At the time, the libuv package only depended on BR2_TOOLCHAIN_HAS_THREADS. However, later on, it was changed in master to depend on BR2_TOOLCHAIN_HAS_THREADS_NPTL, a change which was not taken into account in the cmake 3.7.0 bump that was merged in the next branch.

Due to this, builds of cmake is attempted on architectures that don't provide NPTL thread support, causing a build failure. This commit fixes that by adjusting the dependency.

Fixes:

http://autobuild.buildroot.net/results/16a5e1cbb57c0124537c4f3dc0807ba1eaa975ec/

Signed-off-by Thomas Petazzoni <[email protected]>

---
 package/cmake/Config.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

package/cmake/Config.in +3 -3

index 716d80e..2706db5 100644
@@ -26,7 +26,7 @@ config BR2_PACKAGE_CMAKE_CTEST
 	depends on BR2_USE_WCHAR # libarchive
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on !BR2_STATIC_LIBS
-	depends on BR2_TOOLCHAIN_HAS_THREADS # libuv
+	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # libuv
 	depends on BR2_USE_MMU # libuv
 	help
 	  CTest is a testing tool distributed as a part of CMake. It

@@ -37,9 +37,9 @@ config BR2_PACKAGE_CMAKE_CTEST
 
 	  http://www.cmake.org/
 
-comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, threads"
+comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, NPTL"
 	depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
 	depends on BR2_USE_MMU
 	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
 		BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 || \
-		!BR2_TOOLCHAIN_HAS_THREADS
+		!BR2_TOOLCHAIN_HAS_THREADS_NPTL

Signature · 1 line

2.7.4

Yann E. MORIN

author

2017-02-28 18:07 UTC #20 lore raw

PATCH 5/5 cmake: bump version to 3.7.2

In reply to Yann E. MORIN

From: Vicente Olivert Riera <[email protected]>

Signed-off-by Vicente Olivert Riera <[email protected]>

Signed-off-by Peter Korsgaard <[email protected]>

---
 package/cmake/cmake.hash | 4 ++--
 package/cmake/cmake.mk   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

package/cmake/cmake.hash +2 -2

index 7a22f21..13c0237 100644
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.7/cmake-3.7.1-SHA-256.txt
-sha256 449a5bce64dbd4d5b9517ebd1a1248ed197add6ad27934478976fd5f1f9330e1  cmake-3.7.1.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.2-SHA-256.txt
+sha256 dc1246c4e6d168ea4d6e042cfba577c1acd65feea27e56f5ff37df920c30cae0  cmake-3.7.2.tar.gz

package/cmake/cmake.mk +1 -1

index 107715c..0fd7139 100644
@@ -5,7 +5,7 @@
 ################################################################################
 
 CMAKE_VERSION_MAJOR = 3.7
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).1
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).2
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3c
 CMAKE_LICENSE_FILES = Copyright.txt

Signature · 1 line

2.7.4

Arnout Vandecappelle

2017-03-01 07:49 UTC #21 lore raw

cover package/cmake: re-introduce cmake-3.7

In reply to Yann E. MORIN

Quoted 3 lines · Yann E. MORIN

Once we have this support, we can bump cmake again. We reuse the four original patches, to keep authoorship (although they could well all be squashed into one).

I don't think it makes much sense to keep the 4 separate patches. The history
shows the authorship of the original bump. Having the 4 separate patches just adds noise to the history. Also, Thomas reported that the libuv dependency introduced by the bump is probably incorrect, so we'd have to revert patch 4/5 and part of patch 2/5 again later on... And if the dependency on libuv *is* needed, then you re-introduce a non-bisectable commit between patch 2/5 and 4/5.

Regards,
Arnout

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Thomas Petazzoni

2017-03-01 07:59 UTC #22 lore raw

cover package/cmake: re-introduce cmake-3.7

Hello,

Quoted 6 lines · Arnout Vandecappelle

I don't think it makes much sense to keep the 4 separate patches. The history
shows the authorship of the original bump. Having the 4 separate patches just adds noise to the history. Also, Thomas reported that the libuv dependency introduced by the bump is probably incorrect, so we'd have to revert patch 4/5 and part of patch 2/5 again later on... And if the dependency on libuv *is* needed, then you re-introduce a non-bisectable commit between patch 2/5 and 4/5.

Well, the libuv dependency is incorrect in the sense that ctest doesn't seem to use libuv.

*However*, the libuv dependency is correct in the sense that the CMakeLists.txt checks it, and if not, builds the cmake built-in version of libuv. But since for the target we only build ctest, this whole libuv is not used.

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Thomas Petazzoni

2017-03-01 21:14 UTC #23 lore raw

cover package/cmake: re-introduce cmake-3.7

In reply to Yann E. MORIN

Hello,

Quoted 10 lines · Yann E. MORIN

Thomas Petazzoni (1):
cmake: adjust dependencies added for libuv
Vicente Olivert Riera (3):
cmake: bump version to 3.7.0
cmake: bump version to 3.7.1
cmake: bump version to 3.7.2
Yann E. MORIN (1):
core/pkg-cmake: provide our own platform description

All applied to master. Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Thomas Petazzoni

2017-03-02 08:41 UTC #24 lore raw

cover package/cmake: re-introduce cmake-3.7

Hello,

Quoted 8 lines · Thomas Petazzoni

Quoted 8 lines
Thomas Petazzoni (1):
cmake: adjust dependencies added for libuv
Vicente Olivert Riera (3):
cmake: bump version to 3.7.0
cmake: bump version to 3.7.1
cmake: bump version to 3.7.2

Quoted 4 lines

Quoted 2 lines
Yann E. MORIN (1):
core/pkg-cmake: provide our own platform description
All applied to master. Thanks!

Well, it seems like this introduced some issues.

Look for example at:

http://autobuild.buildroot.net/?reason=paho-mqtt-c-v1.1.0

paho-mqtt-c builds fine at commit 9951d5c931c419a32d31cc2a67d3a5c388efbed6 (before the CMake changes), but fails to build at commit 609df3acf644e97d0aa4a66db8998d93f8543f3b (right after the CMake changes).

Here is a minimal defconfig to reproduce the problem:

BR2_arcle=y
BR2_archs38=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_PAHO_MQTT_C=y
# BR2_TARGET_ROOTFS_TAR is not set

The fastd problems could also be related, but I haven't checked, see
http://autobuild.buildroot.net/?reason=fastd-18.

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Yann E. MORIN

author

2017-03-02 17:39 UTC #25 lore raw

cover package/cmake: re-introduce cmake-3.7

Thomas, All,

On 2017-03-02 09:41 +0100, Thomas Petazzoni spake thusly:

Quoted 13 lines · Thomas Petazzoni

Quoted 12 lines
Quoted 11 lines
Thomas Petazzoni (1):
cmake: adjust dependencies added for libuv
Vicente Olivert Riera (3):
cmake: bump version to 3.7.0
cmake: bump version to 3.7.1
cmake: bump version to 3.7.2
Yann E. MORIN (1):
core/pkg-cmake: provide our own platform description

Quoted 7 lines

Quoted 1 line
All applied to master. Thanks!
Well, it seems like this introduced some issues.
Look for example at:
http://autobuild.buildroot.net/?reason=paho-mqtt-c-v1.1.0

This package is wrong: it checks the system type to decide whether it should link with -ldld or not:

https://github.com/eclipse/paho.mqtt.c/blob/master/src/CMakeLists.txt#L50

This is stupid.

Instead, it should check if the lib is needed or not, and available or mot, like any other lib, and then decide to fail or deactivate features.

Quoted 2 lines

The fastd problems could also be related, but I haven't checked, see
http://autobuild.buildroot.net/?reason=fastd-18.

Similarly broken:

https://git.universe-factory.net/fastd/tree/cmake/config.cmake#n1
https://git.universe-factory.net/fastd/tree/cmake/config.cmake#n14

I'll try a hack on it, by adding:

# Impersonate the Linux system, which we really are in fact... set(CMAKE_SYSTEM_NAME Linux)

in Buildroot.cmake and see if that fixes the build....

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'