Currently, we tell cmake where to look for our own custom platform
description by passing the path to the moduls directory on the command
line.
However, this causes two different problems.
First, some packages simply set CMAKE_MODULE_PATH in their
CMakeList.txt, thus overriding our own path, and then our platform
description is not found.
Second, cmake may internally call sub-cmake (e.g. in the try_compile
macro), but the CMAKE_MODULE_PATH is not automatically passed down in
this case.
For the first problem, we could hunt down and fix all offenders, but
this is an endless endeavour, especially since packagers are told to do
so on the cmake wiki [0]:
CMAKE_MODULE_PATH
tell CMake to search first in directories listed in
CMAKE_MODULE_PATH when you use FIND_PACKAGE() or INCLUDE()
SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/MyCMakeScripts)
FIND_PACKAGE(HelloWorld)
The second problem could be solved by passing yet another variable on
the command line, that tells cmake to explicitly pass arbitrary
variables down to sub-cmake calls:
-DCMAKE_TRY_COMPILE_PLATFORM_VARIABLES=CMAKE_MODULE_PATH
However, this only covers the case of try_compile. Even though no other
case is known yet, we'd still risk missing locations where we would need
to propagate CMAKE_MODULE_PATH, even some where we'd have no solution
like for try_compile.
Instead, ngladitz on IRC suggested that CMAKE_MODULE_PATH be set
directly from the toolchain file.
And indeed this fixes both problems explained above.
So be it.
[0] https://cmake.org/Wiki/CMake_Useful_Variables
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Mosquitto combined with version 2.1.0 of libwebsockets yields a failing
system. Version 2.1.1 restores the websocket interface again.
Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit 0552a367db ("Remove --{enable, disable}-debug configure flags.")
we do not pass --enable-debug to configure script. The patch to remove -Werror
in this case is thus no longer needed.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The LINES variable is automatically set by bash to represent the number
of lines in the terminal. That variable can be set when the shell
receives SIGWINCH.
If the shell does receive SIGWINCH after our LINES array is filled, the
content of the array is mangled.
Rename the variable to avoid that.
Fixes#9456
Reported-by: George Y. <georgebrmz@oss3d.com>
Reported-by: Paul Stewart <paulstewartis@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gdk-pixbuf-loader support is enabled by default but it silently fail to
generate gdk-pixbuf.loaders file when host != target.
For exemple on ARM target:
output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la
g_module_open() failed for output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la: output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so: wrong ELF class: ELFCLASS32
But it doesn't break the build.
When host = target using the Sourcery CodeBench AMD64 2016.11 toolchain
optimized for x86_68 AMD Puma/Jaguar or AMD Steamroller, it break the
build due to "Illegal instruction".
output/host/usr/bin/gdk-pixbuf-query-loaders libpixbufloader-svg.la
Illegal instruction (core dumped)
Since this option is broken for cross-compilation, disable it.
Fixes:
http://autobuild.buildroot.net/results/393/393145bc9bcb93d6df55ec8c63725c3d9a299957
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The bump of python-enum to version 0.4.6 in commit
636df89872 forgot to update the license
information. Even though the PKG-INFO file still pretends it's GPLv2
or Python license, the only license file available is LICENSE.GPL-3
(which indicates a GPLv3 license), and the comment header in the
source code is pretty clear:
This is free software: you may copy, modify, and/or distribute
this work under the terms of the GNU General Public License as
published by the Free Software Foundation; version 3 of that
license or any later version. No warranty expressed or
implied. See the file ‘LICENSE.GPL-3’ for details.
Fixes:
http://autobuild.buildroot.net/results/7fec1c7cde710f523263e74b1849f1f4488b7d26/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
