This patch adds a new infrastructure for golang based packages.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout:
- Rewrap comments to 80 columns.
- Create a global definition of GO_TARGET_ENV.
- <PKG>_GO_ENV is appended to the default env instead of replacing it.
- Add a note to inner-golang-package that only target is supported.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
-Ofast (introduced in GCC 4.6) It combines the existing optimization level -O3
with options that can affect standards compliance but result in better optimized
code. For example, -Ofast enables -ffast-math.
Signed-off-by: Joshua Henderson <joshua.henderson@microchip.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This enables a user to build a complete system using these
options. It is important to note that not all packages will
build correctly to start with.
Modeled after OpenWRT approach
https://github.com/openwrt/openwrt/blob/master/config/Config-build.in#L176
A good testing tool to check a target's elf files for compliance
to an array of hardening techniques can be found here:
https://github.com/slimm609/checksec.sh
[Peter: reword fortify help texts, glibc comment]
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Autotools-based packages that do not need C++ but check for it, and use
libtool, will fail to configure on distros that lack /lib/cpp.
This is the case for example on Arch Linux, where expat fails to build
with:
configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
This is because libtool uses AC_PROC_CXXCPP, which can not be avoided,
and does require a cpp that passes some "sanity" checks (does not choke
on valid input, but does choke on invalid input). So we can use neither
/bin/false nor /bin/true...
We instead need something that can digest some basic C++ preprocessor
input. We can't use the target preprocessor: that does not work, because
it obviously has no C++ cupport:
arm-linux-cpp.br_real: error: conftest.cpp: C++ compiler not
installed on this system
We can however consider that the host machine does have a C++ compiler,
so we use the host' cpp, which is gcc's compiler wrapper that ends up
calling the host's C++ preprocessor.
That would give us a valid C++ preprocessor when we don't have one, in
fact. But autotools will then correctly fail anyway, because there is
indeed no C++ compiler at all, as we can see in this excerpt of a
configure log from expat:
checking whether we are using the GNU C++ compiler... no
checking whether false accepts -g... no
checking dependency style of false... none
checking how to run the C++ preprocessor... cpp
checking whether the false linker (/home/ymorin/dev/buildroot/O/host/bin/arm-linux-ld) supports shared libraries... yes
libtool.m4: error: problem compiling CXX test program
checking for false option to produce PIC... -DPIC
checking if false PIC flag -DPIC works... no
checking if false static flag works... no
checking if false supports -c -o file.o... no
checking if false supports -c -o file.o... (cached) no
checking whether the false linker (/home/ymorin/dev/buildroot/O/host/bin/arm-linux-ld) supports shared libraries... yes
So, using the host's C++ preprocessor (by way of gcc's wrapper) leads to
a working situation, where the end result is as expected.
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: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This macro allows to test if HOSTCC supports a specific option. It is
needed to pass '-no-pie' on recent Debian, Ubuntu and Gentoo hosts.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Sometimes it can be interesting to call back into buildroot from a
post-build/image script (E.G. make printvars or similar). For this to work
correctly with out-of-tree builds we need to pass O= to make, but this is
currently not available in the environment of post-build/image scripts.
In concept, O could be derrived from BUILD_DIR (E.G. by stripping /build),
but directly exporting O is cleaner.
O= cannot be exported globally as it interferes with various build systems,
so instead add it to EXTRA_ENV.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/share' | xargs sed -i 's%$(HOST_DIR)/usr/share%$(HOST_DIR)/share%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/include' | xargs sed -i 's%$(HOST_DIR)/usr/include%$(HOST_DIR)/include%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/lib' | xargs sed -i 's%$(HOST_DIR)/usr/lib%$(HOST_DIR)/lib%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now $(HOST_DIR)/lib and $(HOST_DIR)/usr/lib are the same directory, it
doesn't make sense to pass both to LDFLAGS.
Also use $(HOST_DIR)/lib instead of $(HOST_DIR)/usr/lib for the RPATH.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a step towards eliminating $(HOST_DIR)/usr. It allows us to
convert all packages installing things into
$(HOST_DIR)/usr/$(GNU_TARGET_NAME) (i.e., binutils and gcc) without
affecting the rest.
To allow compatibility with packages that still use $(HOST_DIR)/usr as
the prefix, create a symlink from usr/$(GNU_TARGET_NAME) to
../$(GNU_TARGET_NAME).
Note that the symlink creation will break when $(HOST_DIR)/usr/lib
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
Effectively, the usr/ part is removed from $(STAGING_SUBDIR) (and
therefore from $(STAGING_DIR)), so update the definition of that
variable right away.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
All packages that can use NLS support will have to depend on
host-gettext, as it provides the tools for generating .mo files from
.po files.
In addition, all packages may need to depend on gettext (and link with
-lintl) if the full-blown gettext implementation is provided by
libintl and not by the C library.
In order to avoid repeating such conditions everywhere, this commit
introduces two variables:
- TARGET_NLS_DEPENDENCIES, which packages that may use NLS support
should unconditionally add to their <pkg>_DEPENDENCIES variable.
- TARGET_NLS_LIBS, which packages can use to pass through LIBS or
LDFLAGS when the package build system needs help to realize that it
should link against libintl.
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>
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>
We are going to use DISABLE_NLS not only for disabling NLS support,
but also to explicitly enable it. Therefore, this preparatory commit
renames it to NLS_OPTS, which is consistent with other foo_OPTS
variables defined in package/Makefile.in.
While at it, we replace the := assignments by regular = assignments.
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>
Since BR2_STRIP_strip and BR2_STRIP_noine are mutually exclusive (being
part of a choice), we can simplify the logic.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In some cases, passing STRIP=true is not sufficient to disable striping
altogether, as some (incorrectly generated?) configure scripts will
ignore a ${STRIP} that is not a full path.
This is the case, for example, for nmap, which ends up using the host
strip command when we pass STRIP=true:
checking for arm-buildroot-linux-gnueabihf-strip... no
checking for strip... /usr/bin/strip
configure: WARNING: using cross tools not prefixed with host triplet
[--SNIP--]
/usr/bin/install -c -c -m 755 nping /home/ymorin/dev/buildroot/O/target/usr/bin/nping
/usr/bin/strip -x /home/ymorin/dev/buildroot/O/target/usr/bin/nping
/usr/bin/strip: Unable to recognise the format of the input file `/home/ymorin/dev/buildroot/O/target/usr/bin/nping'
We fix that by forcing a full path to the strip sommand when it is
disabled: STRIP=/bin/true
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Buildroot has a mechanism to detect a too-old or missing tar program on the
host machine, and builds a custom host-tar if needed. An example situation
is a RHEL5 host machine, where tar is knowingly too old.
The apply-patches script also employs tar, in case the patches come as an
archive. However, tar is called as 'tar' without any absolute path, and the
environment does not point in any way to the possibly custom tar. As a
result, the too-old-tar is called. A particular problem is the flag '-a'
which is missing on e.g. RHEL5.
Previously, this problem went unnoticed: tar would fail, but apply-patches
did not notice it, and the overall return code of the script was 'success'.
However, commit d5ae67b4 added 'set -e' to the script, causing any error to
halt execution of the script with an error.
Fix the problem by adding the Buildroot-built host tools to the PATH when
calling apply-patches.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit f71a621d91, we are using the
SED variable in the main Makefile. However, this variable is only
defined in package/Makefile.in, which gets included only when a
configuration is defined.
This means that, if you do:
$ make menuconfig savedefconfig
without a configuration defined, it fails with:
/bin/bash: /BR2_DEFCONFIG=/d: No such file or directory
Makefile:898: recipe for target 'savedefconfig' failed
make[1]: *** [savedefconfig] Error 127
This issue affects users of the "buildroot-submodule" project, which
does menuconfig+savedefconfig automatically. They worked around this
issue in commit
d12676b608,
but really "make menuconfig savedefconfig" should work out of the box.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This new waf-package infrastructure simplifies writing waf-based
packages. It can be used by our six current such packages, plus a
later-incoming one by Romain.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
- rename <pkg>_BUNDLED_WAF to <pkg>_NEEDS_EXTERNAL_WAF, which
involves inverting the meaning of the boolean.
- always add the host-python dependency
- add a default value for <pkg>_NEEDS_EXTERNAL_WAF (defaults to NO)
- remove the unneeded <pkg>_MAKE related definitions.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The BR2_TOOLCHAIN_EXTERNAL_PREFIX variable is already qstripped and
stored in the TOOLCHAIN_EXTERNAL_PREFIX variable in
toolchain-external.mk, so use this variable everywhere.
This will be useful for a later patch that makes the derivation of
TOOLCHAIN_EXTERNAL_PREFIX a little more complex.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Arnout: split off into separate patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This unique NAME is used to construct a per br2-external tree variable,
BR2_EXTERNAL_$(NAME)_PATH, which contains the path to the br2-external
tree.
This variable is available both from Kconfig (set in the Kconfig
snippet) and from the .mk files.
Also, display the NAME and its path as a comment in the menuconfig.
This will ultimately allow us to support multiple br2-external trees at
once, with that NAME (and thus BR2_EXTERNAL_$(NAME)) uniquely defining
which br2-external tree is being used.
The obvious outcome is that BR2_EXTERNAL should now no longer be used to
refer to the files in the br2-external tree; that location is now known
from the BR2_EXTERNAL_$(NAME)_PATH variable instead. This means we no
longer need to expose, and must stop from from exposing BR2_EXTERNAL as
a Kconfig variable.
Finally, this also fixes a latent bug in the pkg-generic infra, where we
would so far always refer to BR2_EXTERNAL (even if not set) to filter
the names of packages (to decide whether they are a bootloader, a
toolchain or a simple package).
Note: since the variables in the Makefile and in Kconfig are named the
same, the one we computed early on in the Makefile will be overridden by
the one in .config when we have it. Thus, even though they are set to
the same raw value, the one from .config is quoted and, being included
later in the Makefile, will take precedence, so we just re-include the
generated Makefile fragment a third time before includeing the
br2-external's Makefiles. That's unfortunate, but there is no easy way
around that as we do want the two variables to be named the same in
Makefile and Kconfig (and we can't ask the user to un-quote that variable
himself either), hence this little dirty triple-inclusion trick.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The pkg-config settings in HOST_CONFIGURE_OPTS and HOST_MAKE_ENV have
diverged over time, so they now use different _LIBDIR and
_ALLOW_SYSTEM_{CFLAGS,LIBS} settings.
Conceptually _CONFIGURE_OPTS should be a superset of _MAKE_ENV, so move the
definitions around and define _CONFIGURE_OPTS in terms of _MAKE_ENV instead
of repeating the individual settings.
Do this both for the target and host variant for consistency.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This variable has been unused for a long time, so we can get rid of its
definition.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We used to do a special handling of Linux kernel modules when stripping
target binaries because there's some special precious data in modules
that we must keep for them to properly operate. This is for example true
for stack unwinding data etc.
It turned out there're cases when our existing "strip --strip-unneeded"
doesn't work well. For example this removes .debug_frame section used by
Linux on ARC for stack unwinding, refer to [1] and [2] for more details.
Now Linux kernel may strip modules as a part of "modules_install" target
if INSTALL_MOD_STRIP=1 is passed in command line. And so we'll do
allowing kernel decide how to strip modules in the best way.
Still note as of today Linux kernel strips modules uniformly for all
arches with "strip" command, so this commit alone doesn't solve
mentioned problem but it opens a possibility to add later a patch to the
kernel which will strip modules for ARC differently - and that's our
plan for mainline kernel.
[1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86
[2] http://lists.busybox.net/pipermail/buildroot/2016-September/172161.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 6f8162cf8c. This is
causing too many problems that are not easy to solve.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
HOST_CFLAGS includes a search path for HOST_DIR/usr/include using -I.
When HOST_CFLAGS is used by a package, these flags are passed to the
compiler ahead of flags passed by the package's internal make system.
If a package has a header file with the same name as a header file in
HOST_DIR, this causes the toolchain to prefer the file from the system
include directory because its -I appears first on the command
line. Conflicts should prefer the file provided by the package. This
can be accomplished by using -isystem, which is more appropriate then
-I for system-level include paths.
Real-world example: libfdt might be installed in HOST_DIR to install a
patched version of QEMU that does not bundle libfdt. Meanwhile, the
u-boot package provides its own copy of libfdt.h that is modified from
upstream. If libfdt is also installed into HOST_DIR, then
host-uboot-tools fails to build because it grabs the libfdt.h from the
HOST_DIR area instead of using the patched version from its own source
tree. This patch corrects this issue.
This assumes the -isystem flag is supported by the host compiler,
which is the case since gcc 3.0 at least.
Signed-off-by: David Raeman <draeman@bbn.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For fortran detection, some projects check for fortran availability
using the FC/FCFLAGS variables, and others for the legacy F77/FFLAGS
ones.
So, make sure the legacy fortran F77 and FFLAGS variables are set in
TARGET_CONFIGURE_OPTS.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
TARGET_FCFLAGS is already added to TARGET_CONFIGURE_OPTS, but was not
defined so far. This change fixes this.
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Benjamin Kamath <bkamath@spaceflight.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-Og (introduced in GCC 4.8) lets you optimize for debugging experience,
which can be useful for when you want optimized code that is nonetheless
debuggable.
Signed-off-by: Martin Kelly <martin@surround.io>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
So far, our LDFLAGS for the BR2_BINFMT_FLAT case were only used on
Blackfin. However, passing -elf2flt in LDFLAGS is wrong. Indeed,
LDFLAGS are not linker flags, but flags passed to the compiler when
linking.
If you pass -elf2flt to the compiler when linking, it is understood as
"-e lf2flt", i.e "the entry point is named lf2flt", which isn't
exactly the intention. We in fact need to pass -Wl,-elf2flt in LDFLAGS
as well, so that the compiler passes -elf2flt down to the linker.
For some reason, this option does not cause an issue with the Blackfin
toolchain, but it does with either a Buildroot toolchain for Cortex-M
or an OSELAS toolchain for Cortex-M. We have verified that passing
-Wl,-elf2flt continues to work with the Blackfin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit dc95d50fe3 (correct gettext handling for musl) introduced a last
minute typo, fix that.
Thanks to Thomas Petazzoni for noticing.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Based on a patch by Bernd Kuhls.
The AM_GNU_GETTEXT autotools macro misdetects musl gettext support as it
checks for internal glibc symbols. Work around it by forcing libc gettext
support when musl is used for the supported gettext api levels.
As this is a generic issue for any package using AM_GNU_GETTEXT, add it to
the global TARGET_CONFIGURE_ARGS instead of for each affected package.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we only support two levels of stach-smashing protection:
- entirely disabled,
- protect _all_ functions with -fstack-protector-all.
-fstack-protector-all tends to be far too aggressive and impacts
performance too much to be worth on a real product.
Add a choice that allows us to select between different levels of
stack-smashing protection:
- none
- basic (NEW)
- strong (NEW)
- all
The differences are documented in the GCC online documentation:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
[yann.morin.1998@free.fr:
- rebase
- add legacy handling
- SSP-strong depends on gcc >= 4.9
- slightly simple ifeq-block in package/Makefile.in
- keep the comment in the choice; add a comment shen strong is not
available
- drop the defaults (only keep the legacy)
- update commit log
]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- only show the choice if the toolchain has SSP support
- add details for the BR2_SSP_ALL option that it has a significant
performance impact.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
HOSTCC_VERSION is no longer used since gcc switched to the package
infrastructure in e236fe481. It was in fact no longer needed since we
dropped support for gcc 4.3.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If system tools are selected, the host's lib/ directory may shadow
libraries from the system which are configured differently and do not
have all of the symbols required by the system tool.
Since buildroot now uses rpath everywhere, LD_LIBRARY_PATH should not
be necessary anyways.
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the toolchain is always wrapped and the wrapper already passes
BR2_TARGET_OPTIMIZATION (through BR_ADDITIONAL_CFLAGS), there is no longer
any need to pass it in TARGET_CFLAGS as well.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since we always have a toolchain wrapper now, we can move the ccache
call to the toolchain wrapper.
The hostcc ccache handling obviously stays.
The global addition of ccache to TARGET_CC/CXX is removed, but many
individual packages and infras still add it. This means we have a
chain like this: ccache -> toolchain-wrapper -> ccache -> gcc
However, this is fairly harmless: for cache misses, the inner ccache
just adds overhead and for cache hits, the inner ccache is never
called. Later patches will remove these redundant ccache calls.
As a side effect, perl now supports ccache as well.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Danomi Manchego <danomimanchego123@gmail.com>
Cc: Károly Kasza <kaszak@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
The boost and jack2 packages fail to build when PARALLEL_JOBS is empty
so instead of using an empty PARALLEL_JOBS don't use it in the MAKE
variable when top-level parallel make is being used.
To simplify the use of top-level parallel make, check the MAKEFLAGS
variable to know automatically if the -j option is being used, also use
the "=" operator instead of the ":=" operator because the MAKEFLAGS
variable can be checked only in a "recursively expanded variable".
The "override" keyword must be used in order to change the automatic
variable "MAKE".
When the top-parallel make is being used the sub-make are called without
specifying the "-j" option in order to let GNU make share the job slots
specified in the top make. This is done because GNU make is able
to share the job slots available between each instance of make so if you
want to increase the number of jobs you just need to increase the <jobs>
value in the top make -j<jobs> command.
If we specify the -j<jobs> option in each instance of make, it is less
efficient, e.g. in a processor with 8 cores we specify -j9 in each instance:
the number of processes goes up to 81 because each sub-make can execute
9 processes. The excessive number of processes is not a good thing
because in my tests even -j16 is slower than -j9.
Instead if we don't specify the -j<jobs> option in the sub-make, the top
make share the job slots automatically between each instance, so the
number of process in this examples goes up to 9 that is faster than
using up to 81 processes.
e.g. when the -j3 option is specified only in the top make:
possible state n. 1:
process 1 - <packagea>-build
process 2 - <packagea>-build
process 3 - <packagea>-build
possible state n. 2:
process 1 - <packagea>-extract
process 2 - <packageb>-configure
process 3 - <packagec>-build
possible state n. 3:
process 1 - <packagea>-build make -j1
process 2 - <packageb>-build make -j1
process 3 - <packagec>-build make -j1
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Adding this flag when BR2_ENABLE_DEBUG is activated make several
packages to produce binaries that do not work as expected (e.g., dhcp,
lame, nano). Moreover, the help message of BR2_ENABLE_DEBUG does not
say it is adding this flag. It is supposed to build packages with
debugging symbols enabled. So, let it do that only.
* package/Makefile.in: Do not add --{enable,disable}-debug flags.
* package/pkg-autotools.mk: Remove ENABLE_DEBUG as it is not set
anymore.
Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that IPv6 is mandatory remove support for non-IPv6 tweaks/variables
in the package infra.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This definition of HOSTFC is completely wrong.
"$(HOSTLD)" should be "$(HOSTFC)". Also, "echo" always succeeds, so
"which g77 || type -p g77 || echo gfortran" is never run.
Anyway, HOSTFC is most likely set to "/use/bin/ld" and nobody has
complained about it before me, so I guess it is not used at all.
At least grepping HOSTFC, FC_FOR_BUILD did not hit any packages.
Drop HOSTFC and FC_FOR_BUILD.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: fix issues noticed by Arnout:
- Rewrap the linux/Config.in paragraph
- Revert the "is a toolchain dependency" -> "has a toolchain
dependency" change from pkg-generic.mk, as the original was
correct.]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
