2007-08-22 19:47:22 +08:00
|
|
|
ifndef MAKE
|
2014-07-26 00:38:37 +08:00
|
|
|
MAKE := make
|
2007-01-31 01:33:53 +08:00
|
|
|
endif
|
2007-07-17 20:09:07 +08:00
|
|
|
ifndef HOSTMAKE
|
2014-07-26 00:38:37 +08:00
|
|
|
HOSTMAKE = $(MAKE)
|
2007-07-17 20:09:07 +08:00
|
|
|
endif
|
2021-10-02 02:08:32 +08:00
|
|
|
HOSTMAKE := $(shell which $(HOSTMAKE) || type -p $(HOSTMAKE) || echo make)
|
2007-07-17 20:09:07 +08:00
|
|
|
|
2015-04-08 08:53:36 +08:00
|
|
|
# If BR2_JLEVEL is 0, scale the maximum concurrency with the number of
|
package-infra: limit the number of // jobs
The current code spawns as many jobs as up to twice the number of CPUs.
On small-class machines like laptops, with a limitted amount of memory,
but still a few CPUs (real or hyperthreads), the HDD becomes a bottleneck,
and it becomes almost impossible to do anythiong else while there is a
build in progress.
Limit the number of jobs to the number of CPUs plus one.
Even on fast machines with fast HDDs, this settings keeps the machine
fully busy (for those packages that can build in parallel, of course).
For example, building qemu or the linux kernel kept my hyperthreaded
hexa Core i7 with 18GiB of RAM, busy at 99% (I never ever managed to
get 100% even with more jobs, not even 200); while on my hyperthreaded
dual Core i5 with only 4GiB and a slow HDD, I still topped at 100% CPU,
while still able to do some work involving the HDD.
If the number of processors is not available, assume one.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Nathan Lynch <ntl@pobox.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-05-10 11:56:01 +08:00
|
|
|
# CPUs. An additional job is used in order to keep processors busy
|
2012-06-16 17:37:17 +08:00
|
|
|
# while waiting on I/O.
|
package-infra: limit the number of // jobs
The current code spawns as many jobs as up to twice the number of CPUs.
On small-class machines like laptops, with a limitted amount of memory,
but still a few CPUs (real or hyperthreads), the HDD becomes a bottleneck,
and it becomes almost impossible to do anythiong else while there is a
build in progress.
Limit the number of jobs to the number of CPUs plus one.
Even on fast machines with fast HDDs, this settings keeps the machine
fully busy (for those packages that can build in parallel, of course).
For example, building qemu or the linux kernel kept my hyperthreaded
hexa Core i7 with 18GiB of RAM, busy at 99% (I never ever managed to
get 100% even with more jobs, not even 200); while on my hyperthreaded
dual Core i5 with only 4GiB and a slow HDD, I still topped at 100% CPU,
while still able to do some work involving the HDD.
If the number of processors is not available, assume one.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Nathan Lynch <ntl@pobox.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-05-10 11:56:01 +08:00
|
|
|
# If the number of processors is not available, assume one.
|
2012-06-16 17:37:17 +08:00
|
|
|
ifeq ($(BR2_JLEVEL),0)
|
2014-07-26 00:38:37 +08:00
|
|
|
PARALLEL_JOBS := $(shell echo \
|
package-infra: limit the number of // jobs
The current code spawns as many jobs as up to twice the number of CPUs.
On small-class machines like laptops, with a limitted amount of memory,
but still a few CPUs (real or hyperthreads), the HDD becomes a bottleneck,
and it becomes almost impossible to do anythiong else while there is a
build in progress.
Limit the number of jobs to the number of CPUs plus one.
Even on fast machines with fast HDDs, this settings keeps the machine
fully busy (for those packages that can build in parallel, of course).
For example, building qemu or the linux kernel kept my hyperthreaded
hexa Core i7 with 18GiB of RAM, busy at 99% (I never ever managed to
get 100% even with more jobs, not even 200); while on my hyperthreaded
dual Core i5 with only 4GiB and a slow HDD, I still topped at 100% CPU,
while still able to do some work involving the HDD.
If the number of processors is not available, assume one.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Nathan Lynch <ntl@pobox.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-05-10 11:56:01 +08:00
|
|
|
$$((1 + `getconf _NPROCESSORS_ONLN 2>/dev/null || echo 1`)))
|
2012-06-16 17:37:17 +08:00
|
|
|
else
|
2014-07-26 00:38:37 +08:00
|
|
|
PARALLEL_JOBS := $(BR2_JLEVEL)
|
2012-06-16 17:37:17 +08:00
|
|
|
endif
|
2012-06-12 00:09:37 +08:00
|
|
|
|
2022-10-17 03:30:14 +08:00
|
|
|
# Only build one job at a time, *and* to not randomise goals and
|
|
|
|
|
# prerequisites ordering in make 4.4+
|
|
|
|
|
MAKE1 := $(HOSTMAKE) -j1 $(if $(findstring --shuffle,$(MAKEFLAGS)),--shuffle=none)
|
2015-07-01 16:10:46 +08:00
|
|
|
override MAKE = $(HOSTMAKE) \
|
|
|
|
|
$(if $(findstring j,$(filter-out --%,$(MAKEFLAGS))),,-j$(PARALLEL_JOBS))
|
2008-07-01 21:30:26 +08:00
|
|
|
|
2014-04-01 14:25:47 +08:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_BUILDROOT),y)
|
|
|
|
|
TARGET_VENDOR = $(call qstrip,$(BR2_TOOLCHAIN_BUILDROOT_VENDOR))
|
|
|
|
|
else
|
|
|
|
|
TARGET_VENDOR = buildroot
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Sanity checks
|
|
|
|
|
ifeq ($(TARGET_VENDOR),)
|
|
|
|
|
$(error BR2_TOOLCHAIN_BUILDROOT_VENDOR is not allowed to be empty)
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(TARGET_VENDOR),unknown)
|
|
|
|
|
$(error BR2_TOOLCHAIN_BUILDROOT_VENDOR cannot be 'unknown'. \
|
2014-10-26 02:29:31 +08:00
|
|
|
It might be confused with the native toolchain)
|
2014-04-01 14:25:47 +08:00
|
|
|
endif
|
|
|
|
|
|
2012-06-08 09:52:16 +08:00
|
|
|
# Compute GNU_TARGET_NAME
|
2024-09-30 04:14:54 +08:00
|
|
|
# FDPIC on ARM requires a special target name: it has no OS field and must
|
|
|
|
|
# use the suffix -uclinuxfdpiceabi.
|
|
|
|
|
ifeq ($(BR2_arm)$(BR2_armeb):$(BR2_BINFMT_FDPIC),y:y)
|
|
|
|
|
GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-uclinuxfdpiceabi
|
|
|
|
|
else
|
2014-07-26 00:38:37 +08:00
|
|
|
GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
|
2024-09-30 04:14:54 +08:00
|
|
|
endif
|
2013-07-20 20:52:14 +08:00
|
|
|
|
2024-05-12 18:06:27 +08:00
|
|
|
# FLAT binary format needs uclinux, except RISC-V which needs the
|
|
|
|
|
# regular linux name.
|
|
|
|
|
ifeq ($(BR2_BINFMT_FLAT):$(BR2_riscv),y:)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_OS = uclinux
|
2013-07-20 20:52:14 +08:00
|
|
|
else
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_OS = linux
|
2013-07-20 20:52:14 +08:00
|
|
|
endif
|
2010-12-29 03:10:27 +08:00
|
|
|
|
2013-07-01 03:29:09 +08:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
LIBC = uclibc
|
2014-05-06 05:17:06 +08:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
LIBC = musl
|
2022-07-27 00:39:49 +08:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_USES_GLIBC),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
LIBC = gnu
|
2022-08-22 03:01:52 +08:00
|
|
|
else ifeq ($(BR_BUILDING),y)
|
2022-07-27 00:39:49 +08:00
|
|
|
# This happens if there is a bug in Buildroot that allows an
|
|
|
|
|
# architecture configuration that isn't supported by any library.
|
|
|
|
|
$(error No C library enabled, this is not possible.)
|
2010-12-29 03:10:27 +08:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# The ABI suffix is a bit special on ARM, as it needs to be
|
2013-07-14 06:27:31 +08:00
|
|
|
# -uclibcgnueabi for uClibc EABI, and -gnueabi for glibc EABI.
|
|
|
|
|
# This means that the LIBC and ABI aren't strictly orthogonal,
|
|
|
|
|
# which explains why we need the test on LIBC below.
|
|
|
|
|
ifeq ($(BR2_arm)$(BR2_armeb),y)
|
2010-12-29 03:10:27 +08:00
|
|
|
ifeq ($(LIBC),uclibc)
|
2014-07-26 00:38:37 +08:00
|
|
|
ABI = gnueabi
|
2010-12-29 03:10:27 +08:00
|
|
|
else
|
2014-07-26 00:38:37 +08:00
|
|
|
ABI = eabi
|
2010-12-29 03:10:27 +08:00
|
|
|
endif
|
2013-08-24 02:40:16 +08:00
|
|
|
|
|
|
|
|
ifeq ($(BR2_ARM_EABIHF),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
ABI := $(ABI)hf
|
arch: improve ARM floating point support and add support for EABIhf
This commit introduces the support for the EABIhf ABI, next to the
existing support we have for EABI and OABI (even though OABI support
is deprecated). EABIhf allows to improve performance of floating point
workload by using floating point registers to transfer floating point
arguments when calling functions, instead of using integer registers
to do, as is done in the 'softfp' floating point model of EABI.
In addition to this, this commit introduces a list of options for the
floating point support:
* Software floating point
* VFP
* VFPv3
* VFPv3-D16
* VFPv4
* VFPv4-D16
and it introduces some logic to make sure the options are only visible
when it makes sense, depending on the ARM core being selected. This is
however made complicated by the fact that certain VFP capabilities are
mandatory on some cores, but optional on some other cores. The kconfig
logic tries to achieve the following goals:
* Hide options that are definitely not possible.
* Use safe default values (i.e for Cortex-A5 and A7, the presence of
the VFPv4 unit is optional, so we default on software floating
point on these cores)..
* Show the available possibilities, even if some of them are not
necessarily working on a particular core (again, for the Cortex-A5
and A7 cores, there is no way of knowing whether the particular
variant used by the user has VFPv4 or not, so we select software
floating point by default, but still show VFP/VFPv3/VFPv4 options).
It is worth noting that this commit doesn't add support for all
possible -mfpu= values on ARM. We haven't added support for fpa, fpe2,
fpe3, maverick (those four are only used on very old ARM cores), for
vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16,
vfpv4-sp-d16. They can be added quite easily if needed thanks to the
new organization of the Config.in options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 16:03:14 +08:00
|
|
|
endif
|
2010-12-29 03:10:27 +08:00
|
|
|
endif
|
|
|
|
|
|
2012-01-06 03:31:43 +08:00
|
|
|
# For FSL PowerPC there's SPE
|
2023-08-21 00:30:29 +08:00
|
|
|
ifeq ($(BR2_POWERPC_CPU_HAS_SPE),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
ABI = spe
|
2012-01-06 03:31:43 +08:00
|
|
|
# MPC8540s are e500v1 with single precision FP
|
|
|
|
|
ifeq ($(BR2_powerpc_8540),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_ABI += -mabi=spe -mfloat-gprs=single -Wa,-me500
|
2012-01-06 03:31:43 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_powerpc_8548),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_ABI += -mabi=spe -mfloat-gprs=double -Wa,-me500x2
|
2012-01-06 03:31:43 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_powerpc_e500mc),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_ABI += -mabi=spe -mfloat-gprs=double -Wa,-me500mc
|
2012-01-06 03:31:43 +08:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2012-12-06 03:36:36 +08:00
|
|
|
# Use longcalls option for Xtensa globally.
|
|
|
|
|
# The 'longcalls' option allows calls across a greater range of addresses,
|
|
|
|
|
# and is required for some packages. While this option can degrade both
|
|
|
|
|
# code size and performance, the linker can usually optimize away the
|
|
|
|
|
# overhead when a call ends up within a certain range.
|
2014-03-31 01:57:46 +08:00
|
|
|
#
|
2015-08-13 06:20:02 +08:00
|
|
|
# Use auto-litpools for Xtensa globally.
|
2014-03-31 01:57:46 +08:00
|
|
|
# Collecting literals into separate section can be advantageous if that
|
|
|
|
|
# section is placed into DTCM at link time. This is applicable for code
|
|
|
|
|
# running on bare metal, but makes no sense under linux, where userspace
|
|
|
|
|
# is isolated from the physical memory details. OTOH placing literals into
|
|
|
|
|
# separate section breaks build of huge source files, because l32r
|
|
|
|
|
# instruction can only access literals in 256 KBytes range.
|
|
|
|
|
#
|
2012-12-06 03:36:36 +08:00
|
|
|
ifeq ($(BR2_xtensa),y)
|
2015-08-13 06:20:02 +08:00
|
|
|
TARGET_ABI += -mlongcalls -mauto-litpools
|
2012-12-06 03:36:36 +08:00
|
|
|
endif
|
|
|
|
|
|
2017-07-04 22:03:51 +08:00
|
|
|
STAGING_SUBDIR = $(GNU_TARGET_NAME)/sysroot
|
2012-07-15 09:12:05 +08:00
|
|
|
STAGING_DIR = $(HOST_DIR)/$(STAGING_SUBDIR)
|
2010-12-29 03:10:27 +08:00
|
|
|
|
2008-03-12 21:07:10 +08:00
|
|
|
ifeq ($(BR2_OPTIMIZE_0),y)
|
2015-10-15 06:19:10 +08:00
|
|
|
TARGET_OPTIMIZATION = -O0
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_OPTIMIZE_1),y)
|
2015-10-15 06:19:10 +08:00
|
|
|
TARGET_OPTIMIZATION = -O1
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_OPTIMIZE_2),y)
|
2015-10-15 06:19:10 +08:00
|
|
|
TARGET_OPTIMIZATION = -O2
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_OPTIMIZE_3),y)
|
2015-10-15 06:19:10 +08:00
|
|
|
TARGET_OPTIMIZATION = -O3
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
2016-05-19 05:17:55 +08:00
|
|
|
ifeq ($(BR2_OPTIMIZE_G),y)
|
|
|
|
|
TARGET_OPTIMIZATION = -Og
|
|
|
|
|
endif
|
2008-03-12 21:07:10 +08:00
|
|
|
ifeq ($(BR2_OPTIMIZE_S),y)
|
2015-10-15 06:19:10 +08:00
|
|
|
TARGET_OPTIMIZATION = -Os
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
2018-03-27 03:34:05 +08:00
|
|
|
ifeq ($(BR2_OPTIMIZE_FAST),y)
|
|
|
|
|
TARGET_OPTIMIZATION = -Ofast
|
|
|
|
|
endif
|
2021-05-25 20:27:36 +08:00
|
|
|
ifeq ($(BR2_ENABLE_DEBUG),)
|
|
|
|
|
TARGET_DEBUGGING = -g0
|
|
|
|
|
endif
|
2008-03-12 21:07:10 +08:00
|
|
|
ifeq ($(BR2_DEBUG_1),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_DEBUGGING = -g1
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_DEBUG_2),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_DEBUGGING = -g2
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_DEBUG_3),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_DEBUGGING = -g3
|
2008-03-12 21:07:10 +08:00
|
|
|
endif
|
|
|
|
|
|
2018-01-24 12:09:41 +08:00
|
|
|
TARGET_LDFLAGS = $(call qstrip,$(BR2_TARGET_LDFLAGS))
|
|
|
|
|
|
2024-07-19 23:27:19 +08:00
|
|
|
# musl's dynamic loader doesn't support DT_TEXTREL, which results in a runtime
|
|
|
|
|
# crash if it gets used. The "-z text" linker option issues a build-time error
|
|
|
|
|
# when DT_TEXREL is used, so we capture the problem earlier.
|
|
|
|
|
#
|
|
|
|
|
# See also: https://www.openwall.com/lists/musl/2020/09/25/4
|
2024-08-06 05:53:56 +08:00
|
|
|
#
|
package/Makefile.in: work around buggy buildsystems wrt LDFLAGS
Some buildsystems (or their use of it by packages) will cause flags in
LDFLAGS to be re-orderded, or even dropped, causing some
incomprehensible mayhem... For example, gpsd [0] has this in its
SConscript [1](typoes not mines, for once):
591 # scons uses gcc, or clang, to link. Thus LDFLAGS does not serve its
592 # traditional function of providing arguments to ln. LDFLAGS set in the
593 # environment before running scons get moved into CCFLAGS by scons.
594 # LDFLAGS set while running scons get ignored.
[--SNIP--]
611 for i in ["ARFLAGS",
612 "CCFLAGS",
613 "CFLAGS",
614 "CPPFLAGS",
615 "CXXFLAGS",
616 "LDFLAGS",
617 "LINKFLAGS",
618 "SHLINKFLAGS",
619 ]:
620 if i in os.environ:
621 # MergeFlags() puts the options where scons wants them, not
622 # where you asked them to go.
623 env.MergeFlags(Split(os.getenv(i)))
So, when LDFLAGS (our TARGET_LDFLAGS) contains "-z text" (without the
quotes), that gets turned into a command line like (line-splitted for
readability):
[...]/buildroot/output/host/bin/aarch64_be-buildroot-linux-musl-gcc \
-o gpsd-3.25/drivers/driver_rtcm2.os \
-c \
--sysroot=[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot \
-O3 -g0 \
-z \
-fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \
gpsd-3.25/drivers/driver_rtcm2.c
Notice how there is a lone "-z" without any following keyword.
This then causes a build failure that looks totally unrelated [2]:
In file included from gpsd-3.25/drivers/../include/gpsd.h:36,
from gpsd-3.25/drivers/driver_rtcm2.c:65:
gpsd-3.25/drivers/../include/os_compat.h:40:8: error: redefinition of ‘struct timespec’
40 | struct timespec {
| ^~~~~~~~
In file included from [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/sys/select.h:16,
from gpsd-3.25/drivers/../include/gpsd.h:31:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/bits/alltypes.h:237:8: note: originally defined here
237 | struct timespec { time_t tv_sec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321); long tv_nsec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321); };
| ^~~~~~~~
gpsd-3.25/drivers/../include/os_compat.h:48:5: error: conflicting types for ‘clock_gettime’; have ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
48 | int clock_gettime(clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
In file included from gpsd-3.25/drivers/../include/gpsd.h:33:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/time.h:104:5: note: previous declaration of ‘clock_gettime’ with type ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
104 | int clock_gettime (clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
scons: *** [gpsd-3.25/drivers/driver_rtcm2.os] Error 1
scons: building terminated because of errors.
make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/gpsd-3.25/.stamp_built] Error 2
make: *** [Makefile:83: _all] Error 2
Although undocumented, neither in gcc not ld (clang unchecked by lack of
a clang toolchain here, and by lack of clang knowledge), -z accepts the
keyword to be snatch-glued onto it, like -zkeyword, rather than be
spearated with a space. So, use that to pass -ztext.
Fixes:
http://autobuild.buildroot.org/results/c03/c039989947b960ac6af17c87090366abc26dcb6d/
http://autobuild.buildroot.net/results/bc35d3e7b0e8c59c776652070650af3c749250ee/
[0] Our other scons-based package, mongodb, does not build for another
reason that probably hides the same issue as seen with gpsd.
[1] As explained in gpsd's SConscript (se above), Scons does play tricks
with variables:
https://scons.org/doc/production/HTML/scons-man.html#f-MergeFlags
https://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags
Quoting:
Flag values are translated according to the prefix found, and added
to the following construction variables:
[...]
-Wl, LINKFLAGS
[...]
- CCFLAGS
[...]
Any other strings not associated with options are assumed to be the
names of libraries and added to the $LIBS construction variable.
So in our case, it finds that -z is an unknown option that matches the
'-' prefix, so it is added to CFLAGS, while 'text' is a string on its
own, so added to LIBS, and thus it would try to link with -ltext
(supposedly, because we do not even go that far). Funnily enough, we can
se that "-Wl," is a known option prefix, that is added to LINKFLAGS (to
properly be used with gcc or clang, not ld).
As a consequence, gpsd's buildsystem does drop -ztext from the link
flags, and only passes it to the compile flags, which brings us back to
before we banned textrels in a1a2f498d7ec (package/Makefile.in: ban
textrels on musl toolchains). Fixing gpsd is a task for another,
separate patch...
[2] I spent quite some time to look at recent, time-related changes in
Buildroot, especially due to the infamous time64_t issues... Alas, that
was not related, and only a git-bisect pinpointed the actual issue. Poor
polar bears...
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: J. Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2024-08-09 21:08:22 +08:00
|
|
|
# NOTE: We're using "-ztext" instead of "-Wl,-z,text" here, because some
|
2024-08-06 05:53:56 +08:00
|
|
|
# packages pass TARGET_LDFLAGS directly to ld rather than gcc, and ld doesn't
|
|
|
|
|
# support -Wl,[...]. -z is supported by both gcc and clang, so it probably
|
|
|
|
|
# won't cause us problems.
|
package/Makefile.in: work around buggy buildsystems wrt LDFLAGS
Some buildsystems (or their use of it by packages) will cause flags in
LDFLAGS to be re-orderded, or even dropped, causing some
incomprehensible mayhem... For example, gpsd [0] has this in its
SConscript [1](typoes not mines, for once):
591 # scons uses gcc, or clang, to link. Thus LDFLAGS does not serve its
592 # traditional function of providing arguments to ln. LDFLAGS set in the
593 # environment before running scons get moved into CCFLAGS by scons.
594 # LDFLAGS set while running scons get ignored.
[--SNIP--]
611 for i in ["ARFLAGS",
612 "CCFLAGS",
613 "CFLAGS",
614 "CPPFLAGS",
615 "CXXFLAGS",
616 "LDFLAGS",
617 "LINKFLAGS",
618 "SHLINKFLAGS",
619 ]:
620 if i in os.environ:
621 # MergeFlags() puts the options where scons wants them, not
622 # where you asked them to go.
623 env.MergeFlags(Split(os.getenv(i)))
So, when LDFLAGS (our TARGET_LDFLAGS) contains "-z text" (without the
quotes), that gets turned into a command line like (line-splitted for
readability):
[...]/buildroot/output/host/bin/aarch64_be-buildroot-linux-musl-gcc \
-o gpsd-3.25/drivers/driver_rtcm2.os \
-c \
--sysroot=[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot \
-O3 -g0 \
-z \
-fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \
gpsd-3.25/drivers/driver_rtcm2.c
Notice how there is a lone "-z" without any following keyword.
This then causes a build failure that looks totally unrelated [2]:
In file included from gpsd-3.25/drivers/../include/gpsd.h:36,
from gpsd-3.25/drivers/driver_rtcm2.c:65:
gpsd-3.25/drivers/../include/os_compat.h:40:8: error: redefinition of ‘struct timespec’
40 | struct timespec {
| ^~~~~~~~
In file included from [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/sys/select.h:16,
from gpsd-3.25/drivers/../include/gpsd.h:31:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/bits/alltypes.h:237:8: note: originally defined here
237 | struct timespec { time_t tv_sec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321); long tv_nsec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321); };
| ^~~~~~~~
gpsd-3.25/drivers/../include/os_compat.h:48:5: error: conflicting types for ‘clock_gettime’; have ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
48 | int clock_gettime(clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
In file included from gpsd-3.25/drivers/../include/gpsd.h:33:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/time.h:104:5: note: previous declaration of ‘clock_gettime’ with type ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
104 | int clock_gettime (clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
scons: *** [gpsd-3.25/drivers/driver_rtcm2.os] Error 1
scons: building terminated because of errors.
make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/gpsd-3.25/.stamp_built] Error 2
make: *** [Makefile:83: _all] Error 2
Although undocumented, neither in gcc not ld (clang unchecked by lack of
a clang toolchain here, and by lack of clang knowledge), -z accepts the
keyword to be snatch-glued onto it, like -zkeyword, rather than be
spearated with a space. So, use that to pass -ztext.
Fixes:
http://autobuild.buildroot.org/results/c03/c039989947b960ac6af17c87090366abc26dcb6d/
http://autobuild.buildroot.net/results/bc35d3e7b0e8c59c776652070650af3c749250ee/
[0] Our other scons-based package, mongodb, does not build for another
reason that probably hides the same issue as seen with gpsd.
[1] As explained in gpsd's SConscript (se above), Scons does play tricks
with variables:
https://scons.org/doc/production/HTML/scons-man.html#f-MergeFlags
https://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags
Quoting:
Flag values are translated according to the prefix found, and added
to the following construction variables:
[...]
-Wl, LINKFLAGS
[...]
- CCFLAGS
[...]
Any other strings not associated with options are assumed to be the
names of libraries and added to the $LIBS construction variable.
So in our case, it finds that -z is an unknown option that matches the
'-' prefix, so it is added to CFLAGS, while 'text' is a string on its
own, so added to LIBS, and thus it would try to link with -ltext
(supposedly, because we do not even go that far). Funnily enough, we can
se that "-Wl," is a known option prefix, that is added to LINKFLAGS (to
properly be used with gcc or clang, not ld).
As a consequence, gpsd's buildsystem does drop -ztext from the link
flags, and only passes it to the compile flags, which brings us back to
before we banned textrels in a1a2f498d7ec (package/Makefile.in: ban
textrels on musl toolchains). Fixing gpsd is a task for another,
separate patch...
[2] I spent quite some time to look at recent, time-related changes in
Buildroot, especially due to the infamous time64_t issues... Alas, that
was not related, and only a git-bisect pinpointed the actual issue. Poor
polar bears...
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: J. Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2024-08-09 21:08:22 +08:00
|
|
|
#
|
|
|
|
|
# We're using "-ztext" instead of "-z text" here, because some buildsystems
|
|
|
|
|
# (like scons, for gpsd) will reorder and/or drop LDFLAGS, causing a lone
|
|
|
|
|
# "-z" to be passed and the "text" keyword to be dropped otherwise. Both
|
|
|
|
|
# gcc and ld supports that, so it probably won't cause us problems.
|
2024-07-19 23:27:19 +08:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_USES_MUSL):$(BR2_STATIC_LIBS),y:)
|
package/Makefile.in: work around buggy buildsystems wrt LDFLAGS
Some buildsystems (or their use of it by packages) will cause flags in
LDFLAGS to be re-orderded, or even dropped, causing some
incomprehensible mayhem... For example, gpsd [0] has this in its
SConscript [1](typoes not mines, for once):
591 # scons uses gcc, or clang, to link. Thus LDFLAGS does not serve its
592 # traditional function of providing arguments to ln. LDFLAGS set in the
593 # environment before running scons get moved into CCFLAGS by scons.
594 # LDFLAGS set while running scons get ignored.
[--SNIP--]
611 for i in ["ARFLAGS",
612 "CCFLAGS",
613 "CFLAGS",
614 "CPPFLAGS",
615 "CXXFLAGS",
616 "LDFLAGS",
617 "LINKFLAGS",
618 "SHLINKFLAGS",
619 ]:
620 if i in os.environ:
621 # MergeFlags() puts the options where scons wants them, not
622 # where you asked them to go.
623 env.MergeFlags(Split(os.getenv(i)))
So, when LDFLAGS (our TARGET_LDFLAGS) contains "-z text" (without the
quotes), that gets turned into a command line like (line-splitted for
readability):
[...]/buildroot/output/host/bin/aarch64_be-buildroot-linux-musl-gcc \
-o gpsd-3.25/drivers/driver_rtcm2.os \
-c \
--sysroot=[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot \
-O3 -g0 \
-z \
-fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \
gpsd-3.25/drivers/driver_rtcm2.c
Notice how there is a lone "-z" without any following keyword.
This then causes a build failure that looks totally unrelated [2]:
In file included from gpsd-3.25/drivers/../include/gpsd.h:36,
from gpsd-3.25/drivers/driver_rtcm2.c:65:
gpsd-3.25/drivers/../include/os_compat.h:40:8: error: redefinition of ‘struct timespec’
40 | struct timespec {
| ^~~~~~~~
In file included from [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/sys/select.h:16,
from gpsd-3.25/drivers/../include/gpsd.h:31:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/bits/alltypes.h:237:8: note: originally defined here
237 | struct timespec { time_t tv_sec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321); long tv_nsec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321); };
| ^~~~~~~~
gpsd-3.25/drivers/../include/os_compat.h:48:5: error: conflicting types for ‘clock_gettime’; have ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
48 | int clock_gettime(clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
In file included from gpsd-3.25/drivers/../include/gpsd.h:33:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/time.h:104:5: note: previous declaration of ‘clock_gettime’ with type ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
104 | int clock_gettime (clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
scons: *** [gpsd-3.25/drivers/driver_rtcm2.os] Error 1
scons: building terminated because of errors.
make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/gpsd-3.25/.stamp_built] Error 2
make: *** [Makefile:83: _all] Error 2
Although undocumented, neither in gcc not ld (clang unchecked by lack of
a clang toolchain here, and by lack of clang knowledge), -z accepts the
keyword to be snatch-glued onto it, like -zkeyword, rather than be
spearated with a space. So, use that to pass -ztext.
Fixes:
http://autobuild.buildroot.org/results/c03/c039989947b960ac6af17c87090366abc26dcb6d/
http://autobuild.buildroot.net/results/bc35d3e7b0e8c59c776652070650af3c749250ee/
[0] Our other scons-based package, mongodb, does not build for another
reason that probably hides the same issue as seen with gpsd.
[1] As explained in gpsd's SConscript (se above), Scons does play tricks
with variables:
https://scons.org/doc/production/HTML/scons-man.html#f-MergeFlags
https://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags
Quoting:
Flag values are translated according to the prefix found, and added
to the following construction variables:
[...]
-Wl, LINKFLAGS
[...]
- CCFLAGS
[...]
Any other strings not associated with options are assumed to be the
names of libraries and added to the $LIBS construction variable.
So in our case, it finds that -z is an unknown option that matches the
'-' prefix, so it is added to CFLAGS, while 'text' is a string on its
own, so added to LIBS, and thus it would try to link with -ltext
(supposedly, because we do not even go that far). Funnily enough, we can
se that "-Wl," is a known option prefix, that is added to LINKFLAGS (to
properly be used with gcc or clang, not ld).
As a consequence, gpsd's buildsystem does drop -ztext from the link
flags, and only passes it to the compile flags, which brings us back to
before we banned textrels in a1a2f498d7ec (package/Makefile.in: ban
textrels on musl toolchains). Fixing gpsd is a task for another,
separate patch...
[2] I spent quite some time to look at recent, time-related changes in
Buildroot, especially due to the infamous time64_t issues... Alas, that
was not related, and only a git-bisect pinpointed the actual issue. Poor
polar bears...
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: J. Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2024-08-09 21:08:22 +08:00
|
|
|
TARGET_LDFLAGS += -ztext
|
2024-07-19 23:27:19 +08:00
|
|
|
endif
|
|
|
|
|
|
2018-09-18 05:21:51 +08:00
|
|
|
# By design, _FORTIFY_SOURCE requires gcc optimization to be enabled.
|
|
|
|
|
# Therefore, we need to pass _FORTIFY_SOURCE and the optimization level
|
|
|
|
|
# through the same mechanism, i.e currently through CFLAGS. Passing
|
|
|
|
|
# _FORTIFY_SOURCE through the wrapper and the optimization level
|
|
|
|
|
# through CFLAGS would not work, because CFLAGS are sometimes
|
|
|
|
|
# ignored/overridden by packages, but the flags passed by the wrapper
|
|
|
|
|
# are enforced: this would cause _FORTIFY_SOURCE to be used without any
|
|
|
|
|
# optimization level, leading to a build / configure failure. So we keep
|
|
|
|
|
# passing _FORTIFY_SOURCE and the optimization level both through CFLAGS.
|
2018-01-24 12:09:41 +08:00
|
|
|
ifeq ($(BR2_FORTIFY_SOURCE_1),y)
|
2018-07-11 22:31:08 +08:00
|
|
|
TARGET_HARDENED += -D_FORTIFY_SOURCE=1
|
2018-01-24 12:09:41 +08:00
|
|
|
else ifeq ($(BR2_FORTIFY_SOURCE_2),y)
|
2018-07-11 22:31:08 +08:00
|
|
|
TARGET_HARDENED += -D_FORTIFY_SOURCE=2
|
2022-09-19 05:21:44 +08:00
|
|
|
else ifeq ($(BR2_FORTIFY_SOURCE_3),y)
|
|
|
|
|
TARGET_HARDENED += -D_FORTIFY_SOURCE=3
|
2018-01-24 12:09:41 +08:00
|
|
|
endif
|
|
|
|
|
|
2022-03-08 19:49:49 +08:00
|
|
|
TARGET_CPPFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
|
Config.in: introduce BR2_TIME_BITS_64 option for Y2038 compatibility
Y2038 is now almost only 15 years away, and embedded systems built
today are potentially going to still be operational in 15 years, and
even though they are supposed to receive updates by then, we all know
how things go, and potentially some of these embedded systems will not
receive any update.
In 2038, the signed 32-bit representation of time_t used on 32-bit
architectures will overflow, causing all time-related functions to go
back in time in a surprising way.
The Linux kernel has already been modified to support a 64-bit
representation of time_t on 32-bit architectures, but from a C library
perspective, the situation varies:
- glibc uses this 64-bit time_t representation on 32-bit systems
since glibc 2.34, but only if -D_TIME_BITS=64 is
specified. Therefore, this commit adds an option to add this flag
globally to the build, when glibc is the C library and the
architecture is not 64-bit.
- musl uses unconditionally a 64-bit time_t representation on 32-bit
systems since musl 1.2.0. So there is nothing to do here since
Buildroot has been using a musl >= 1.2.0, used since Buildroot
2020.05. No Buildroot option is needed here.
- uClibc-ng does not support a 64-bit time_t representation on 32-bit
systems, so systems using uClibc-ng will not be Y2038 compliant, at
least for now. No Buildroot option is needed here.
It should be noted that being Y2038-compliant will only work if all
application/library code is correct. For example if an
application/library stores a timestamp in an "int" instead of using
the proper time_t type, then the mechanisms described above will not
fix this, and the application/library will continue to be broken in
terms of Y2038 support.
Possible discussions points about this patch:
- Should we have an option at all, or should we unconditionally pass
-D_TIME_BITS=64, like we have been doing for _FILE_OFFSET_BITS=64
for quite some time. The reasoning for having an option is that
the mechanism is itself opt-in in glibc, and generally relatively
new, so it seemed logical for now to make it optional as well in
Buildroot.
- Should we show something (a Config.in comment?) in the musl and
uClibc-ng case to let the user know that the code is Y2038
compliant (musl) or not Y2038 compliant (uClibc-ng). Or should this
discussion be part of the Buildroot documentation?
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-10-13 05:50:08 +08:00
|
|
|
ifeq ($(BR2_TIME_BITS_64),y)
|
|
|
|
|
TARGET_CPPFLAGS += -D_TIME_BITS=64
|
|
|
|
|
endif
|
2018-07-11 22:31:08 +08:00
|
|
|
TARGET_CFLAGS = $(TARGET_CPPFLAGS) $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) $(TARGET_HARDENED)
|
2012-10-11 15:01:10 +08:00
|
|
|
TARGET_CXXFLAGS = $(TARGET_CFLAGS)
|
2016-07-02 00:29:08 +08:00
|
|
|
TARGET_FCFLAGS = $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
|
2007-06-20 19:26:36 +08:00
|
|
|
|
2019-01-13 03:50:39 +08:00
|
|
|
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79509
|
|
|
|
|
ifeq ($(BR2_m68k_cf),y)
|
|
|
|
|
TARGET_CFLAGS += -fno-dwarf2-cfi-asm
|
|
|
|
|
TARGET_CXXFLAGS += -fno-dwarf2-cfi-asm
|
|
|
|
|
endif
|
|
|
|
|
|
2013-05-03 08:39:38 +08:00
|
|
|
ifeq ($(BR2_BINFMT_FLAT),y)
|
2024-05-12 18:06:27 +08:00
|
|
|
ifeq ($(BR2_riscv),y)
|
2021-10-26 15:17:20 +08:00
|
|
|
TARGET_CFLAGS += -fPIC
|
|
|
|
|
endif
|
2021-10-26 15:17:19 +08:00
|
|
|
ELF2FLT_FLAGS = $(if $($(PKG)_FLAT_STACKSIZE),\
|
|
|
|
|
-Wl$(comma)-elf2flt="-r -s$($(PKG)_FLAT_STACKSIZE)",\
|
|
|
|
|
-Wl$(comma)-elf2flt=-r)
|
|
|
|
|
TARGET_CFLAGS += $(ELF2FLT_FLAGS)
|
|
|
|
|
TARGET_CXXFLAGS += $(ELF2FLT_FLAGS)
|
|
|
|
|
TARGET_FCFLAGS += $(ELF2FLT_FLAGS)
|
|
|
|
|
TARGET_LDFLAGS += $(ELF2FLT_FLAGS)
|
2013-05-03 08:39:38 +08:00
|
|
|
endif
|
|
|
|
|
|
2013-10-06 22:19:11 +08:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_BUILDROOT),y)
|
2017-07-05 19:14:19 +08:00
|
|
|
TARGET_CROSS = $(HOST_DIR)/bin/$(GNU_TARGET_NAME)-
|
2010-10-16 05:01:08 +08:00
|
|
|
else
|
2017-07-05 19:14:19 +08:00
|
|
|
TARGET_CROSS = $(HOST_DIR)/bin/$(TOOLCHAIN_EXTERNAL_PREFIX)-
|
2007-02-07 02:19:38 +08:00
|
|
|
endif
|
2010-06-25 21:04:08 +08:00
|
|
|
|
2020-10-18 06:17:40 +08:00
|
|
|
# gcc-4.7 and later ships with wrappers that will automatically pass
|
|
|
|
|
# arguments to the binutils tools. Those are paths to necessary linker
|
|
|
|
|
# plugins.
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
|
|
|
|
|
TARGET_GCC_WRAPPERS_PREFIX = gcc-
|
|
|
|
|
endif
|
|
|
|
|
|
2013-09-03 00:06:27 +08:00
|
|
|
# Define TARGET_xx variables for all common binutils/gcc
|
2020-10-18 06:17:40 +08:00
|
|
|
TARGET_AR = $(TARGET_CROSS)$(TARGET_GCC_WRAPPERS_PREFIX)ar
|
2010-06-25 21:04:08 +08:00
|
|
|
TARGET_AS = $(TARGET_CROSS)as
|
2011-05-03 05:58:20 +08:00
|
|
|
TARGET_CC = $(TARGET_CROSS)gcc
|
|
|
|
|
TARGET_CPP = $(TARGET_CROSS)cpp
|
|
|
|
|
TARGET_CXX = $(TARGET_CROSS)g++
|
|
|
|
|
TARGET_FC = $(TARGET_CROSS)gfortran
|
|
|
|
|
TARGET_LD = $(TARGET_CROSS)ld
|
2020-10-18 06:17:40 +08:00
|
|
|
TARGET_NM = $(TARGET_CROSS)$(TARGET_GCC_WRAPPERS_PREFIX)nm
|
|
|
|
|
TARGET_RANLIB = $(TARGET_CROSS)$(TARGET_GCC_WRAPPERS_PREFIX)ranlib
|
2012-11-07 13:01:20 +08:00
|
|
|
TARGET_READELF = $(TARGET_CROSS)readelf
|
2010-06-25 21:04:08 +08:00
|
|
|
TARGET_OBJCOPY = $(TARGET_CROSS)objcopy
|
|
|
|
|
TARGET_OBJDUMP = $(TARGET_CROSS)objdump
|
|
|
|
|
|
2007-08-01 02:06:50 +08:00
|
|
|
ifeq ($(BR2_STRIP_strip),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
STRIP_STRIP_DEBUG := --strip-debug
|
|
|
|
|
TARGET_STRIP = $(TARGET_CROSS)strip
|
|
|
|
|
STRIPCMD = $(TARGET_CROSS)strip --remove-section=.comment --remove-section=.note
|
2017-07-01 20:51:20 +08:00
|
|
|
else
|
2017-07-01 15:42:05 +08:00
|
|
|
TARGET_STRIP = /bin/true
|
2014-07-26 00:38:37 +08:00
|
|
|
STRIPCMD = $(TARGET_STRIP)
|
2007-08-01 02:06:50 +08:00
|
|
|
endif
|
2021-10-02 02:08:32 +08:00
|
|
|
INSTALL := $(shell which install || type -p install)
|
|
|
|
|
UNZIP := $(shell which unzip || type -p unzip) -q
|
2004-10-09 09:06:03 +08:00
|
|
|
|
2024-06-06 01:53:21 +08:00
|
|
|
APPLY_PATCHES = TAR="$(TAR)" PATH=$(HOST_DIR)/bin:$$PATH support/scripts/apply-patches.sh $(if $(QUIET),-s)
|
2014-10-23 00:20:10 +08:00
|
|
|
|
2017-07-05 19:14:22 +08:00
|
|
|
HOST_CPPFLAGS = -I$(HOST_DIR)/include
|
2010-10-30 03:00:26 +08:00
|
|
|
HOST_CFLAGS ?= -O2
|
2012-07-26 01:40:46 +08:00
|
|
|
HOST_CFLAGS += $(HOST_CPPFLAGS)
|
|
|
|
|
HOST_CXXFLAGS += $(HOST_CFLAGS)
|
2017-07-04 22:03:56 +08:00
|
|
|
HOST_LDFLAGS += -L$(HOST_DIR)/lib -Wl,-rpath,$(HOST_DIR)/lib
|
2009-03-17 04:58:08 +08:00
|
|
|
|
2014-10-18 02:48:01 +08:00
|
|
|
# host-intltool should be executed with the system perl, so we save
|
|
|
|
|
# the path to the system perl, before a host-perl built by Buildroot
|
2017-07-05 19:14:19 +08:00
|
|
|
# might get installed into $(HOST_DIR)/bin and therefore appears
|
2014-10-18 02:48:01 +08:00
|
|
|
# in our PATH. This system perl will be used as INTLTOOL_PERL.
|
2021-10-02 02:08:32 +08:00
|
|
|
export PERL=$(shell which perl)
|
2014-10-18 02:48:01 +08:00
|
|
|
|
|
|
|
|
# host-intltool needs libxml-parser-perl, which Buildroot installs in
|
2017-07-05 19:14:21 +08:00
|
|
|
# $(HOST_DIR)/lib/perl, so we must make sure that the system perl
|
2014-10-18 02:48:01 +08:00
|
|
|
# finds this perl module by exporting the proper value for PERL5LIB.
|
2017-07-05 19:14:21 +08:00
|
|
|
export PERL5LIB=$(HOST_DIR)/lib/perl
|
2014-10-18 02:48:01 +08:00
|
|
|
|
2024-01-11 18:56:19 +08:00
|
|
|
TARGET_MAKE_ENV = \
|
|
|
|
|
GIT_DIR=. \
|
|
|
|
|
PATH=$(BR_PATH)
|
2016-10-14 22:09:44 +08:00
|
|
|
|
2014-12-30 15:36:23 +08:00
|
|
|
TARGET_CONFIGURE_OPTS = \
|
2016-10-14 22:09:44 +08:00
|
|
|
$(TARGET_MAKE_ENV) \
|
2014-12-30 15:36:23 +08:00
|
|
|
AR="$(TARGET_AR)" \
|
|
|
|
|
AS="$(TARGET_AS)" \
|
|
|
|
|
LD="$(TARGET_LD)" \
|
|
|
|
|
NM="$(TARGET_NM)" \
|
|
|
|
|
CC="$(TARGET_CC)" \
|
|
|
|
|
GCC="$(TARGET_CC)" \
|
|
|
|
|
CPP="$(TARGET_CPP)" \
|
|
|
|
|
CXX="$(TARGET_CXX)" \
|
|
|
|
|
FC="$(TARGET_FC)" \
|
2016-07-02 00:29:09 +08:00
|
|
|
F77="$(TARGET_FC)" \
|
2014-12-30 15:36:23 +08:00
|
|
|
RANLIB="$(TARGET_RANLIB)" \
|
|
|
|
|
READELF="$(TARGET_READELF)" \
|
|
|
|
|
STRIP="$(TARGET_STRIP)" \
|
|
|
|
|
OBJCOPY="$(TARGET_OBJCOPY)" \
|
|
|
|
|
OBJDUMP="$(TARGET_OBJDUMP)" \
|
|
|
|
|
AR_FOR_BUILD="$(HOSTAR)" \
|
|
|
|
|
AS_FOR_BUILD="$(HOSTAS)" \
|
|
|
|
|
CC_FOR_BUILD="$(HOSTCC)" \
|
|
|
|
|
GCC_FOR_BUILD="$(HOSTCC)" \
|
|
|
|
|
CXX_FOR_BUILD="$(HOSTCXX)" \
|
|
|
|
|
LD_FOR_BUILD="$(HOSTLD)" \
|
|
|
|
|
CPPFLAGS_FOR_BUILD="$(HOST_CPPFLAGS)" \
|
|
|
|
|
CFLAGS_FOR_BUILD="$(HOST_CFLAGS)" \
|
|
|
|
|
CXXFLAGS_FOR_BUILD="$(HOST_CXXFLAGS)" \
|
|
|
|
|
LDFLAGS_FOR_BUILD="$(HOST_LDFLAGS)" \
|
|
|
|
|
FCFLAGS_FOR_BUILD="$(HOST_FCFLAGS)" \
|
|
|
|
|
DEFAULT_ASSEMBLER="$(TARGET_AS)" \
|
|
|
|
|
DEFAULT_LINKER="$(TARGET_LD)" \
|
|
|
|
|
CPPFLAGS="$(TARGET_CPPFLAGS)" \
|
|
|
|
|
CFLAGS="$(TARGET_CFLAGS)" \
|
|
|
|
|
CXXFLAGS="$(TARGET_CXXFLAGS)" \
|
|
|
|
|
LDFLAGS="$(TARGET_LDFLAGS)" \
|
|
|
|
|
FCFLAGS="$(TARGET_FCFLAGS)" \
|
2016-07-02 00:29:09 +08:00
|
|
|
FFLAGS="$(TARGET_FCFLAGS)" \
|
2014-12-30 15:36:23 +08:00
|
|
|
PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
|
|
|
|
|
STAGING_DIR="$(STAGING_DIR)" \
|
|
|
|
|
INTLTOOL_PERL=$(PERL)
|
2007-06-20 19:26:36 +08:00
|
|
|
|
2014-02-10 20:23:08 +08:00
|
|
|
|
2016-10-14 22:09:44 +08:00
|
|
|
HOST_MAKE_ENV = \
|
2024-01-11 18:56:19 +08:00
|
|
|
GIT_DIR=. \
|
2016-10-14 22:09:44 +08:00
|
|
|
PATH=$(BR_PATH) \
|
|
|
|
|
PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
|
|
|
|
|
PKG_CONFIG_SYSROOT_DIR="/" \
|
|
|
|
|
PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 \
|
|
|
|
|
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 \
|
2017-07-05 19:14:23 +08:00
|
|
|
PKG_CONFIG_LIBDIR="$(HOST_DIR)/lib/pkgconfig:$(HOST_DIR)/share/pkgconfig"
|
2009-12-15 20:39:40 +08:00
|
|
|
|
2014-12-30 15:36:23 +08:00
|
|
|
HOST_CONFIGURE_OPTS = \
|
2016-10-14 22:09:44 +08:00
|
|
|
$(HOST_MAKE_ENV) \
|
2014-12-30 15:36:23 +08:00
|
|
|
AR="$(HOSTAR)" \
|
|
|
|
|
AS="$(HOSTAS)" \
|
|
|
|
|
LD="$(HOSTLD)" \
|
|
|
|
|
NM="$(HOSTNM)" \
|
|
|
|
|
CC="$(HOSTCC)" \
|
|
|
|
|
GCC="$(HOSTCC)" \
|
|
|
|
|
CXX="$(HOSTCXX)" \
|
|
|
|
|
CPP="$(HOSTCPP)" \
|
|
|
|
|
OBJCOPY="$(HOSTOBJCOPY)" \
|
|
|
|
|
RANLIB="$(HOSTRANLIB)" \
|
|
|
|
|
CPPFLAGS="$(HOST_CPPFLAGS)" \
|
|
|
|
|
CFLAGS="$(HOST_CFLAGS)" \
|
|
|
|
|
CXXFLAGS="$(HOST_CXXFLAGS)" \
|
|
|
|
|
LDFLAGS="$(HOST_LDFLAGS)" \
|
|
|
|
|
INTLTOOL_PERL=$(PERL)
|
|
|
|
|
|
2014-03-11 04:51:33 +08:00
|
|
|
# This is extra environment we can not export ourselves (eg. because some
|
2013-11-11 23:03:26 +08:00
|
|
|
# packages use that variable internally, eg. uboot), so we have to
|
|
|
|
|
# explicitly pass it to user-supplied external hooks (eg. post-build,
|
|
|
|
|
# post-images)
|
2014-07-26 00:38:37 +08:00
|
|
|
EXTRA_ENV = \
|
2014-04-15 06:31:09 +08:00
|
|
|
PATH=$(BR_PATH) \
|
2014-07-01 06:26:19 +08:00
|
|
|
BR2_DL_DIR=$(BR2_DL_DIR) \
|
2017-07-14 21:04:17 +08:00
|
|
|
BUILD_DIR=$(BUILD_DIR) \
|
2021-05-05 04:51:32 +08:00
|
|
|
CONFIG_DIR=$(CONFIG_DIR) \
|
2023-11-19 02:13:08 +08:00
|
|
|
O=$(CANONICAL_O) \
|
|
|
|
|
PARALLEL_JOBS=$(PARALLEL_JOBS)
|
2009-03-17 21:48:15 +08:00
|
|
|
|
2013-06-07 18:13:46 +08:00
|
|
|
################################################################################
|
2007-06-27 17:48:23 +08:00
|
|
|
# settings we need to pass to configure
|
|
|
|
|
|
|
|
|
|
# does unaligned access trap?
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_TRAP_CHECK = ac_cv_lbl_unaligned_fail=yes
|
2007-06-27 17:48:23 +08:00
|
|
|
ifeq ($(BR2_i386),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_TRAP_CHECK = ac_cv_lbl_unaligned_fail=no
|
2007-06-27 17:48:23 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_x86_64),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_TRAP_CHECK = ac_cv_lbl_unaligned_fail=no
|
2007-06-27 17:48:23 +08:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_m68k),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_TRAP_CHECK = ac_cv_lbl_unaligned_fail=no
|
2007-06-27 17:48:23 +08:00
|
|
|
endif
|
2014-05-13 13:28:21 +08:00
|
|
|
ifeq ($(BR2_powerpc)$(BR2_powerpc64)$(BR2_powerpc64le),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_TRAP_CHECK = ac_cv_lbl_unaligned_fail=no
|
2007-06-27 17:48:23 +08:00
|
|
|
endif
|
|
|
|
|
|
2007-06-27 20:01:27 +08:00
|
|
|
ifeq ($(BR2_ENDIAN),"BIG")
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_C_BIGENDIAN = ac_cv_c_bigendian=yes
|
2007-06-27 20:01:27 +08:00
|
|
|
else
|
2014-07-26 00:38:37 +08:00
|
|
|
BR2_AC_CV_C_BIGENDIAN = ac_cv_c_bigendian=no
|
2007-06-27 20:01:27 +08:00
|
|
|
endif
|
|
|
|
|
|
2016-02-02 00:02:06 +08:00
|
|
|
# AM_GNU_GETTEXT misdetects musl gettext support.
|
|
|
|
|
# musl currently implements api level 1 and 2 (basic + ngettext)
|
|
|
|
|
# http://www.openwall.com/lists/musl/2015/04/16/3
|
package/Makefile.in: fix musl handling
Until now, we had no support for full NLS with the musl C library:
BR2_NEEDS_GETTEXT was only true for uClibc. But the musl C library
provides a stub gettext implementation, which some packages were
failing to recognize as being usable, and therefore we are passing
autoconf cache variables to hint those packages that yes, the C
library has a usable gettext implementation.
However, we are going to enable full NLS support for musl, by giving
the possibility to build gettext libintl with musl. In such a case, we
do not want packages to use the gettext implementation of the C
library, but really the one provided by gettext libintl.
Therefore, we should only pre-seed the
gt_cv_func_gnugettext1_libc*=yes variables if we're on musl but
without gettext libintl. Otherwise packages will fail building because:
- libintl.h is the one from the full-blown gettext implementation, so
it assumes the package will link against -lintl
- the package thinks gettext is provided by the C library, so it
doesn't link with -lintl
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 22:47:51 +08:00
|
|
|
#
|
|
|
|
|
# These autoconf variables should only be pre-seeded when the minimal
|
|
|
|
|
# gettext implementation of musl is used. When the full blown
|
|
|
|
|
# implementation provided by gettext libintl is used, auto-detection
|
|
|
|
|
# works fine, and pre-seeding those values is actually wrong.
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_USES_MUSL):$(BR2_PACKAGE_GETTEXT_PROVIDES_LIBINTL),y:)
|
2016-02-02 00:02:06 +08:00
|
|
|
BR2_GT_CV_FUNC_GNUGETTEXT_LIBC = \
|
2016-02-02 00:19:36 +08:00
|
|
|
gt_cv_func_gnugettext1_libc=yes \
|
2016-02-02 00:02:06 +08:00
|
|
|
gt_cv_func_gnugettext2_libc=yes
|
|
|
|
|
endif
|
|
|
|
|
|
2014-07-26 00:38:37 +08:00
|
|
|
TARGET_CONFIGURE_ARGS = \
|
2007-06-27 17:48:23 +08:00
|
|
|
$(BR2_AC_CV_TRAP_CHECK) \
|
2007-06-27 20:01:27 +08:00
|
|
|
ac_cv_func_mmap_fixed_mapped=yes \
|
|
|
|
|
ac_cv_func_memcmp_working=yes \
|
2008-11-28 22:20:47 +08:00
|
|
|
ac_cv_have_decl_malloc=yes \
|
|
|
|
|
gl_cv_func_malloc_0_nonnull=yes \
|
|
|
|
|
ac_cv_func_malloc_0_nonnull=yes \
|
|
|
|
|
ac_cv_func_calloc_0_nonnull=yes \
|
|
|
|
|
ac_cv_func_realloc_0_nonnull=yes \
|
2011-05-03 21:23:40 +08:00
|
|
|
lt_cv_sys_lib_search_path_spec="" \
|
2016-02-02 00:02:06 +08:00
|
|
|
$(BR2_AC_CV_C_BIGENDIAN) \
|
|
|
|
|
$(BR2_GT_CV_FUNC_GNUGETTEXT_LIBC)
|
2004-10-09 09:06:03 +08:00
|
|
|
|
2013-06-07 18:13:46 +08:00
|
|
|
################################################################################
|
2007-06-27 17:48:23 +08:00
|
|
|
|
system: introduce BR2_SYSTEM_ENABLE_NLS
Until now, the option BR2_ENABLE_LOCALE was more-or-less controlling
whether NLS support was enabled in packages. More precisely, if
BR2_ENABLE_LOCALE=y, we were not doing anything (so some packages
could have NLS support enabled, some not). And only when
BR2_ENABLE_LOCALE was disabled we were explicitly passing
--disable-nls to packages.
This doesn't make much sense, and there is no reason to tie NLS
support to locale support. You may want locale support, but not
necessarily NLS support. Therefore, this commit introduces
BR2_SYSTEM_ENABLE_NLS, which allows to enable/disable NLS support
globally. When this option is enabled, we pass --enable-nls to
packages, otherwise we pass --disable-nls.
In addition, when this option is enabled and the C library doesn't
provide a full-blown implementation of gettext, we select the gettext
package, which will provide the full blown implementation.
It is worth mentioning that this commit has a visible impact for users:
- Prior to this commit, as soon as BR2_ENABLE_LOCALE=y, packages
*could* provide NLS support. It was up to each package to decide
whether they wanted to provide NLS support or not (we were not
passing --enable-nls nor --disable-nls).
- After this commit, it's BR2_SYSTEM_ENABLE_NLS that controls whether
NLS is enabled or disabled, and this option is disabled by default.
Bottom line: with the default of BR2_SYSTEM_ENABLE_NLS disabled, some
packages may lose NLS support that they used to provide. But we
believe it's a reasonable default behavior for Buildroot, where
generally NLS support is not necessary.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 22:47:49 +08:00
|
|
|
ifeq ($(BR2_SYSTEM_ENABLE_NLS),y)
|
|
|
|
|
NLS_OPTS = --enable-nls
|
2017-07-04 22:47:50 +08:00
|
|
|
TARGET_NLS_DEPENDENCIES = host-gettext
|
|
|
|
|
ifeq ($(BR2_PACKAGE_GETTEXT_PROVIDES_LIBINTL),y)
|
|
|
|
|
TARGET_NLS_DEPENDENCIES += gettext
|
|
|
|
|
TARGET_NLS_LIBS += -lintl
|
|
|
|
|
endif
|
2004-10-09 09:06:03 +08:00
|
|
|
else
|
2017-07-04 22:47:48 +08:00
|
|
|
NLS_OPTS = --disable-nls
|
2004-10-09 09:06:03 +08:00
|
|
|
endif
|
|
|
|
|
|
core: alternate solution to disable C++
Some packages that use libtool really need some love to be able to
disable C++ support.
This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
will want a C++ preprocessor that works on valid input *and* fail on
invalid input.
So, providing 'false' as the C++ compiler will then require that we do
have a working C++ preprocessor. Which is totally counter-productive
since we do not have a C++ compiler to start with...
bd39d11d2e (core/infra: fix build on toolchain without C++) was a
previous attempt at fixing this, by using the host's C++ preprocessor.
However, that is very incorrect (that's my code, I can say so!) because
the set of defines will most probably be different for the host and the
target, thus causing all sorts of trouble. For example, on ARM we'd have
to include different headers for soft-float vs hard-float, which is
decided based on a macro, which is not defined for x86, and thus may
redirect to the wrong (and missing) header.
Instead, we notice that libtool uses the magic value 'no' to decide that
a C++ compiler is not available, in which case it skips the call to
AC_PROG_CXXCPP.
Given that 'no' is not provided by any package in Debian and
derivatives, as well as in Fedora, we can assume that no system will
have an executable called 'no'. Hence, we use that as a magic value to
disable C++ detection altogether.
Fixes: #10846 (again)
Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-27 19:00:22 +08:00
|
|
|
# We need anything that is invalid. Traditionally, we'd have used 'false' (and
|
|
|
|
|
# we did so in the past). However, that breaks libtool for packages that have
|
|
|
|
|
# optional C++ support (e.g. gnutls), because libtool will *require* a *valid*
|
|
|
|
|
# C++ preprocessor as long as CXX is not 'no'.
|
|
|
|
|
# Now, whether we use 'no' or 'false' for CXX as the same side effect: it is an
|
|
|
|
|
# invalid C++ compiler, and thus will cause detection of C++ to fail (which is
|
|
|
|
|
# expected and what we want), while at the same time taming libtool into
|
|
|
|
|
# silence.
|
2010-12-14 00:27:41 +08:00
|
|
|
ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
|
core: alternate solution to disable C++
Some packages that use libtool really need some love to be able to
disable C++ support.
This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
will want a C++ preprocessor that works on valid input *and* fail on
invalid input.
So, providing 'false' as the C++ compiler will then require that we do
have a working C++ preprocessor. Which is totally counter-productive
since we do not have a C++ compiler to start with...
bd39d11d2e (core/infra: fix build on toolchain without C++) was a
previous attempt at fixing this, by using the host's C++ preprocessor.
However, that is very incorrect (that's my code, I can say so!) because
the set of defines will most probably be different for the host and the
target, thus causing all sorts of trouble. For example, on ARM we'd have
to include different headers for soft-float vs hard-float, which is
decided based on a macro, which is not defined for x86, and thus may
redirect to the wrong (and missing) header.
Instead, we notice that libtool uses the magic value 'no' to decide that
a C++ compiler is not available, in which case it skips the call to
AC_PROG_CXXCPP.
Given that 'no' is not provided by any package in Debian and
derivatives, as well as in Fedora, we can assume that no system will
have an executable called 'no'. Hence, we use that as a magic value to
disable C++ detection altogether.
Fixes: #10846 (again)
Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-27 19:00:22 +08:00
|
|
|
TARGET_CONFIGURE_OPTS += CXX=no
|
2006-12-21 21:51:53 +08:00
|
|
|
endif
|
2004-10-09 09:06:03 +08:00
|
|
|
|
2014-12-04 05:41:29 +08:00
|
|
|
ifeq ($(BR2_STATIC_LIBS),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
SHARED_STATIC_LIBS_OPTS = --enable-static --disable-shared
|
2014-05-26 06:13:00 +08:00
|
|
|
TARGET_CFLAGS += -static
|
|
|
|
|
TARGET_CXXFLAGS += -static
|
2016-07-02 00:29:08 +08:00
|
|
|
TARGET_FCFLAGS += -static
|
2014-05-26 06:12:59 +08:00
|
|
|
TARGET_LDFLAGS += -static
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-12 06:50:09 +08:00
|
|
|
else ifeq ($(BR2_SHARED_LIBS),y)
|
|
|
|
|
SHARED_STATIC_LIBS_OPTS = --disable-static --enable-shared
|
|
|
|
|
else ifeq ($(BR2_SHARED_STATIC_LIBS),y)
|
2014-07-26 00:38:37 +08:00
|
|
|
SHARED_STATIC_LIBS_OPTS = --enable-static --enable-shared
|
package/autotools: add --{enable,disable}-{shared,static} automatically
For target packages, depending on BR2_PREFER_STATIC_LIB, add the
correct combination of --{enable,disable}-{shared,static} flags to
./configure calls.
* When BR2_PREFER_STATIC_LIB is enabled, we pass --enable-static
--disable-shared.
* When BR2_PREFER_STATIC_LIB is disabled, we pass --enable-static
--enable-shared. We enable static libraries since they can still be
useful to statically link applications against some libraries
(sometimes it is useful for size reasons). Static libraries are
anyway only installed in the STAGING_DIR, so it doesn't increase in
any way the size of the TARGET_DIR.
For host packages, always pass --enable-shared and --disable-static.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-05-31 05:57:02 +08:00
|
|
|
endif
|
|
|
|
|
|
toolchain: make paranoid check of library/header paths unconditional
When we introduced support for the paranoid check of unsafe libraries
and headers path with commit 4ac8f78d3771 (Add option for paranoid
unsafe path checking) back in 2014, we made it optional, as we expected
that would break quite a few packages.
Now, almost 8 years later, we only have three packages that explicitly
reference the option (dillo, gnuradio, and libtalloc), either in a patch
or in their .mk.
The option has been enabled by default since 2016, with 61c8854cef2a
(toolchain: enable paranoid unsafe path check by default), and that has
not triggered many build failures in a while.
The minimal defconfig used by test-pkg has also had it enabled as of
b6c98b3549d8 (minimal.config: add BR2_COMPILER_PARANOID_UNSAFE_PATH=y)
in 2017.
It is time to make that globally unconditional now.
There is still a remnant, in our binutils patches. As our toolchain may
get used outside of Buildroot, people may got the expectation that path
poisoning is only a warning, so we keep the current behaviour.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Romain Naour <romain.naour@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-11-08 05:49:03 +08:00
|
|
|
# Used by our binutils patches.
|
2014-12-11 06:53:57 +08:00
|
|
|
export BR_COMPILER_PARANOID_UNSAFE_PATH=enabled
|
|
|
|
|
|
2012-04-17 22:45:19 +08:00
|
|
|
include package/pkg-download.mk
|
2012-07-06 06:06:46 +08:00
|
|
|
include package/pkg-autotools.mk
|
|
|
|
|
include package/pkg-cmake.mk
|
2014-01-11 23:42:07 +08:00
|
|
|
include package/pkg-luarocks.mk
|
2014-02-23 22:17:16 +08:00
|
|
|
include package/pkg-perl.mk
|
2013-12-12 04:26:36 +08:00
|
|
|
include package/pkg-python.mk
|
2014-04-05 23:21:45 +08:00
|
|
|
include package/pkg-virtual.mk
|
2012-07-06 06:06:46 +08:00
|
|
|
include package/pkg-generic.mk
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 23:32:40 +08:00
|
|
|
include package/pkg-kconfig.mk
|
2015-01-12 17:32:06 +08:00
|
|
|
include package/pkg-rebar.mk
|
package-infra: add helper to build kernel modules
The Linux kernel offers a nice and easy-to-use infra to build
out-of-tree kernel modules.
Currently, we have quite a few packages that build kernel modules, and
most duplicate (or rewrite) the same code over-and-over again.
Introduce a new infrastructure that provides helpers to build kernel
modules, so packages do not have to duplicate/rewrite that.
The infrastructure, unlike any other package infra, is not standalone.
It needs another package infra to be used. This is so that packages that
provide both userland and kernel modules can be built easily. So, this
infra only defines post-build and post-install hooks, that will build
the kernel modules after the rest of the package.
We need to override PWD, because some packages will use it to find their
own includes (and other helper files). PWD is inherited from the
environment, so it gets whatever value it had when make was launched,
which happens to be Buildroot's own top source tree. So, we just force
PWD to the proper value, rather than cd-ing first.
Also, no host version is provided, since it does not make sense to build
kernel modules for the host.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-12 08:21:31 +08:00
|
|
|
include package/pkg-kernel-module.mk
|
2016-10-31 00:02:13 +08:00
|
|
|
include package/pkg-waf.mk
|
2018-03-31 21:27:30 +08:00
|
|
|
include package/pkg-golang.mk
|
2018-05-16 03:51:52 +08:00
|
|
|
include package/pkg-meson.mk
|
2020-02-18 05:23:24 +08:00
|
|
|
include package/pkg-qmake.mk
|
2020-12-19 23:35:20 +08:00
|
|
|
include package/pkg-cargo.mk
|
