This change adds support for specifying a build ID for kernel modules.
This is done by setting PKG_BUILD_ID to a hexadecimal string, which will
then be passed to the kernel linker. In addition, when this flag is set,
the build ID debug symbol (.note.gnu.build-id) will not be stripped from
the kernel module. This symbol is exported in sysfs by the kernel (if
the kernel is compiled with CONFIG_KALLSYMS) and so can be used to
uniquely identify a version of a kernel module in a running kernel. This
is useful for keeping track of different versions of a module when doing
experiments and development.
Modules that specify the build ID will be ~100 bytes larger (depending
on the length of the build ID specified). There is no size difference
for kernel modules that do not set this variable.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
SVN-Revision: 47290
gcc 4.4 was removed in r44957 gcc: remove 4.4.7 (only used by avr32)
gcc 4.5 was removed in r36149
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 46722
Remove all rpath entries which do not point to a location below /lib or
/usr/lib and which do not begin with '$ORIGIN'.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 44377
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
Enabling MIPS16 is made conditional on advertising the "mips16" feature
for a specific target since it requires support from the CPU
(HAS_MIPS16) and the actual use of MIPS16 for building packages
(USE_MIPS16).
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 36202
To be safe, build "m16" into the toolchain and target architecture the
same way mips32r2 does:
target-mips_r2_m16_uClibc-0.9.33.2
toolchain-mips_r2_m16_gcc-4.6-linaro_uClibc-0.9.33.2
Signed-off-by: Jay Carlson <nop@nop.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 36198
Create and use a TARGET_ASFLAGS, defaulting to TARGET_CFLAGS.
MIPS .S files reasonably assume they are not in mips16 mode. Because
"-mips16 -mno-mips16" results in -mno-mips16, I can append that to the
TARGET_ASFLAGS. This should be done with $(filter-out)?
Signed-off-by: Jay Carlson <nop@nop.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 36197
Felix Fietkau