Instead of using TARGET_CFLAGS and EXTRA_CFLAGS in cmake and scons
build use the TARGET_CXXFLAGS and EXTRA_CXXFLAGS like it is done for
normal make and configure. configure used TARGET_CXXFLAGS and
EXTRA_CFLAGS for the CXXFLAGS. The package-default.mk sets
"EXTRA_CXXFLAGS = $(EXTRA_CFLAGS)" so using EXTRA_CXXFLAGS flags should
be save.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some packages need out of source tree building with cmake, for example
when building kernel modules.
See an example here:
https://sourceforge.net/p/accel-ppp/code/ci/master/tree/README
Signed-off-by: Luke McKee <hojuruku@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cleanup, rework]
CMAKE_ASM_COMPILER is automatically set to CMAKE_C_COMPILER by CMake, but
CMAKE_C_COMPILER_ARG1 is lost. This causes assembly builds to fail when ccache
is enabled (for example the package fastd on x86).
Fix this by explicitly defining CMAKE_ASM_COMPILER and CMAKE_ASM_COMPILER_ARG1.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 45119
Since GCC 4.7, GCC provides its own wrappers around ar, nm and ranlib, which
should be used for builds with link-time optimization. Since GCC 4.9, using them
actually necessary for LTO builds using convenience libraries to succeed.
There are some packages which try to automatically detect if gcc-{ar,nm,ranlib}
exist (one example is my package "fastd" in the package repository, which tries
to use LTO). This breaks because the OpenWrt build system explicitly sets the
binutils versions of these tools.
As it doesn't cause any issues to use gcc-{ar,nm,ranlib} instead of
{ar,nm,ranlib} even without LTO, this patch just makes OpenWrt use the
GCC-provided versions by default, which fixes the build of such packages with
GCC 4.9.
(I know that builds fail though when clang is used with -flto and
gcc-{ar,nm,ranlib}, but as all OpenWrt toolchains are based on GCC, this isn't
a real issue.)
Completely cleaning the tree (or at least `make clean toolchain/clean`) is
necessary to get a consistent state after the binutils plugins support patch and
this one (as trying to use gcc-{ar,nm,ranlib} with a binutils built without
plugin support will definitely lead to a build failure).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 43784
Hauke Mehrtens