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>
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.
As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.
This also helps preparing the addition of other options to select
shared, shared+static or just static.
Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit adds a Config.in option to the "Build options" submenu to
enable paranoid checking of unsafe paths. This mechanism is added as
an option so that when we'll enable it in the autobuilders, people
trying to reproduce the build failures will be able to do so by just
downloading the configuration file. If instead we were leaving this
feature as an environment variable, everyone would have to remember to
pass this environment variable to reproduce build issues. And certain
build issues triggered by paranoid unsafe patch checking may not be
visible in the build output, for example when they happen during the
execution of configure scripts.
Since this option is fairly advanced, a new submenu inside "Build
options" is created, for Advanced options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
When we set LD_LIBRARY_PATH when building our host tools, we append any
pre-existing value to our custom path:
LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib:$(LD_LIBRARY_PATH)"
But then if LD_LIBRARY_PATH was previously empty, we end up with an
LD_LIBRARY_PATH that ends with a colon.
Also, when we check that an existing LD_LIBRARY_PATH does not contain
CWD, we previously did not look for a zero-length prefix.
Since 'man ld.so' says of LD_LIBRARY_PATH:
A colon-separated list of directories in which to search for ELF
libraries at execution-time. Similar to the PATH environment
variable.
And POSIX states about PATH:
A zero-length prefix is a legacy feature that indicates the current
working directory.
And bash also recognises a zero-length prefix to search in CWD:
A zero-length (null) directory name in the value of PATH indicates
the current directory.
We may thus end up on a system where a zero-length prefix in
LD_LIBRARY_PATH is interpreted as CWD.
Do not append the previous LD_LIBRARY_PATH if it was empty, and check
for a zero-length prefix when checking dependencies.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add and use the "UNZIP" variable instead of calling directly unzip
because the variable contains the "-q" option to silence "unzip" so it
doesn't show the list of files extracted just like when tar files are
being unpacked.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The make "-s" option is used to enable the "Silent operation" so if that
option is used don't print anything as far as there isn't any error.
Add the "-s" option to "apply-patches.sh" to enable silent operation.
[Peter: use the existing QUIET variable]
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To easy up adding optional parameters when calling the
"apply-patches.sh" add and use the "APPLY_PATCHES" variable to execute
the script.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes various build failures caused by the host-perl
series.
Currently, the variables PERL and PERL5LIB are available only during
the configure step of host-intltool, but they are also needed when
running host-intltool, in all packages that depend on
host-intltool. Without them, host-intltool cannot work as it doesn't
find the libxml-parser-perl module installed in
$(HOST_DIR)/usr/lib/perl.
This commit therefore makes the PERL and PERL5LIB variables global, so
that all packages can access them.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A lot of packages ignored BR2_ENABLE_DEBUG. This patch simplifies the handling of
this option by adding the corresponding configure option to the global Makefile
for target packages.
For host packages --disable-debug is added to the global Makefile.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Current setting only allows blackfin to select uclinux as TARGET_OS.
However, some noMMU ARM platforms that using FLAT binary format also need to
select uclinux as TARGET_OS. Fix the dependency.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, pkg-utils.mk (included via package/Makefile.in) is only included
when a configuration file already exists. This means that none of the
utilities it defines are available without .config.
In particular:
- the MESSAGE macro, causing pretty build output. Since some make targets
can be run even without .config, like 'make manual', not having this
pretty printing is odd.
- pkgname, pkgdir: in a subsequent patch, these functions will be used for
the generation of the manual, and since this should work also without
.config, we need these functions to be available.
This patch moves the include of pkg-utils.mk from package/Makefile.in to
Makefile, outside of the check for .config.
This is a quick fix. The full solution involves to minimize the amount of
Makefile code that is guarded by a check on .config. This approach will be
taken in the 2014.11 release cycle.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
GCC has several builtin functions that implement atomic operations. Those
functions are architecture specific and may not be implemented by the
specific toolchain. In case of GCC for ARC those functions rely on
LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't
support those instructions but software tries to use them, then application
will be aborted with Illegal instruction exception. To avoid confusion user
should first specify that their CPU supports atomic extension, which will
allow selection of packages that use builtin atomic functions.
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Generic infra packages might not use LDFLAGS at all so add -static for
static builds to CFLAGS and CXXFLAGS too.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As stated in the buildroot user manual add just a single space before
and after a '=' sign.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Also export BR2_DL_DIR for incoming download helper scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This enables powerpc64 and powerpc64le. Currently, le needs at least
glibc 2.19 and gcc 4.9.0. For gdb, 7.7.1 works (added in an earlier
patch).
[Peter: also disallow gcc 4.8 for ppc64le]
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This variable contains extra environment variables that we can not export
since they are clashing with some build systems (eg. BUILD_DIR with
u-boot).
So, we may need these variables for uses other than the user's hooks
for instrumentation. For example, we'll use them later on to export
BUILD_DIR to the download helper scripts.
Fix comment, too.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This can be useful for post-{build,image} scripts, in case some host-tools
were specifically built to be used by these scripts.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the variables TARGET_PATH and HOST_PATH are not used anymore,
let's remove them.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thanks to the 2 previous patches of the series, BR_PATH contains
all locations in which host-packages may install programs.
This patch replaces the occurrences TARGET_PATH and HOST_PATH with
BR_PATH, everywhere these variables are used in the *.mk files.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the HOST_PATH and TARGET_PATH variables almost contain the same
things, let's factorize this in a single BR_PATH.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This option allows to customize the "vendor" part of the
toolchain tuple, where the toolchain tuple has the form
<arch>-<vendor>-<os>-<libc>. Use this option in situations
where gcc might make different decisions based on the vendor
part of the tuple.
[Thomas: move the config option in a slightly different place, so that
it does not appear between the C library selection and the C library
options.]
Signed-off-by: "Noam Camus" <noamc@ezchip.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The virtual-package infrastructure allows to easily define a
virtual package in a single line:
$ cat package/some-virtual-package/some-virtual-package.mk
$(eval $(virtual-package))
And that's all. :-)
Thanks to Éric for his work on the manual, that prompted the
idea for this virtual-package infrastructure! ;-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Mike Zick <minimod@morethan.org>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
Add -mtext-section-literals into xtensa ABI to fix build issues of
packages with huge sources.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The official Perl documentation refers only to PERL5LIB.
PERLLIB is obsolete, we don't need to be compatible with Perl4.
PERL5LIB is used in all environment, so it is simpler to just export it.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since we now always disable documentation on target, there is no need to
have a separate variable DISABLE_DOCUMENTATION anymore.
Suggested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch removes deprecated symbol BR2_HAVE_DOCUMENTATION and all its
usage. Additionally, it removes the now unused BR2_DEPRECATED_SINCE_2012_11.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: fix s/BUILD_TYPE/SETUP_TYPE/ typo in manual as noted by Samuel]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds the OBJCOPY and RANLIB variables to
HOST_CONFIGURE_OPTS, since grub legacy will need these defined in
order to build properly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also export BUILD_DIR for post-{build,images} hooks, so they do have
a place to store generated files.
Note: this will be more einteresting for the instrumentation of steps,
to come in a later patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order to avoid the work of converting the toolchain-crosstool-ng
logic to the package infrastructure, we remove it from Buildroot,
since it has been deprecated since quite some time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the "BR2_JLEVEL" variable is empty use "make" without
the "-j" option, because to be able to use top-level parallel
make we must not force the number of jobs in sub-make.
Example:
make BR2_JLEVEL= -j8
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit refactors how Stack Smashing Protection support is handled
in Buildroot:
*) It turns the BR2_TOOLCHAIN_BUILDROOT_USE_SSP option into an option
that only enables the SSP support in uClibc, when using the internal
toolchain backend.
*) It adds an hidden BR2_TOOLCHAIN_HAS_SSP option that gets enabled
when the toolchain has SSP support. Here we have the usual dance:
glibc/eglibc in internal/external backend always select this
option, in the case of uClibc/internal, it gets selected when
BR2_TOOLCHAIN_BUILDROOT_USE_SSP is enabled, in the case of
uClibc/external, there is a new configuration option that the user
must select (or not) depending on whether the toolchain has SSP
support.
*) It adds a new options BR2_ENABLE_SSP in the "Build options" menu,
to enable the usage of SSP support, by adding
-fstack-protector-all to the CFLAGS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The TARGET_{CC,CXX,LD,...} variables no longer contain any --sysroot
option, since we're now using a toolchain wrapper for external
toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When building for nommu flat targets the CFLAGS/CXXFLAGS/LDFLAGS must be
adjusted accordingly.
For gcc this means passing along -Wl,-elf2flt to signal the linker.
For ld this means -elf2flt.
Also correct the error in STACKSIZE settings from commit 9edf482d which
is setting gcc flags as ld flags and will surely fail (no package uses
it at the moment so it was never seen).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The current code to set ABI on ARM does the following:
ifeq ($(BR2_arm)$(BR2_armeb),y)
... set ABI without 'hf' suffix ...
else ifeq ($(BR2_ARM_EABIHF),y)
... set ABI with 'hf' suffix ...
endif
But since $(BR2_arm)$(BR2_armeb) will always be 'y' in the cases where
BR2_ARM_EABIHF is 'y', it means that the 'else' part of the condition
will never be used.
Fix this by appending 'hf' to the ABI variable when BR2_ARM_EABIHF is
selected.
[Peter: put EABIhf handling under arm/armeb conditional for consistency]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Blackfin for FDPIC targets uses *-linux-*, however for FLAT targets it
needs *-uclinux-* in order for gcc to build properly.
[Thomas: use a TARGET_OS variable instead of redefining
GNU_TARGET_NAME completely]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current SSP handling is incomplete.
First we need to build uClibc with SSP support for a complete
"experience".
Second, it doesn't hurt to add -fstack-protector-all to the
CFLAGS/CXXFLAGS since most users would expect buildroot to do this
rather than adding the flags themselves.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Currently, when we need to do a conditional on the type of C library
used, we need to take into account the three toolchain backends. As we
are going to add eglibc support to the Buildroot toolchain backend, it
would become even uglier, so this patch introduces two new hidden
options: BR2_TOOLCHAIN_USES_UCLIBC and BR2_TOOLCHAIN_USES_GLIBC, that
exist regardless of the toolchain backend. The entire Buildroot code
base is converted to use those options.
Note that we have intentionally created only one option
(BR2_TOOLCHAIN_USES_GLIBC) for both glibc and eglibc, since they are
essentially the same, as far as Buildroot is concerned.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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>
Add new option <PKG>_FLAT_STACKSIZE. The document needs to be updated.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Just introduce the symbol and options in arch generic Config.in.
Add FLAT types specific compiling flags into package makefile.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The external toolchain wrapper sets sysroot etc. to an absolute path.
By changing this to a relative path, it is possible to move the host
directory to a different location and still have a working build
system.
This only works for a downloaded external toolchain. For a pre-installed
external toolchain, it is possible to move the host directory to a
different location, but not the external toolchain directory (it does work
if the external toolchain directory lies within the host directory). For
an internal or crosstool-ng toolchain, there is no wrapper so updating the
sysroot path should be done in a different way.
See http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html
for information about others things to do to make the host directory
relocatable.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The following changes LDFLAGS from -static to --static if building
with BR2_PREFER_STATIC_LIB so that various components actually build
statically.
Libtool interpret -static as linking statically with libraries that will not
be installed to the libdir; you have to pass it -all-static to force static
linking. Or, pass --static, which libtool passes on blindly to gcc. gcc
and (GNU) ld both interpret --static the same as -static (although this
isn't documented).
Signed-off-by: Andy Kennedy <andy.kennedy@adtran.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Many configure scripts support an option like --disable-doc, --disable-docs
or --disable-documentation. Pass all of these to configure.
In addition, not all Xorg packages accept the --disable-xxx. Instead they
look for xmlto and/or fop and build documentation if they exist. For host
packages, this may lead to build errors because /usr/bin/xmlto uses libxml2
and we set LD_LIBRARY_PATH to point to $(HOST_DIR)/lib, which may contain
a libxml2 as well. So it's essential to disable xmlto for host packages.
Also some whitespace cleanup.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The longcalls option allows calls across a greater range of addresses.
This option may degrade both code size and performance, but
the linker can generally optimize away the unnecessary overhead
when a call ends up within range
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Strip libthread_db the same as any other library, but strip libpthread
with --strip-debug. See the relevant mailing list discussion [1] for
additional details.
[1] http://lists.busybox.net/pipermail/buildroot/2012-October/060126.html
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Give the path to the realdelf binary for the target, similar to how we
do for the other tools.
[Peter: reworded]
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When compiling for the same architecture and libc as the host,
GNU_TARGET_NAME and GNU_HOST_NAME are equal. configure scripts use
these to detect cross-compilation, and will decide that we're doing
native compilation. This may trigger running of executables,
which fail because of missing libraries in the host environment.
To solve this, set the vendor part in GNU_TARGET_NAME to buildroot.
This problem exists for instance in xserver_xorg-server on x86_64.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
With the replacement of GENTARGETS by package-generic, there is a risk
that local packages don't work anymore without any indication of what
is wrong. Therefore, generate an error message if the GENTARGETS,
AUTOTARGETS or CMAKETARGETS macro is still used.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
-mno-abicalls is an old kludge for some (probably) old issue.
Remove it since it's actually harmful, static busybox doesn't build with
it for a modern-ish toolchain (defaults as of this commit, uClibc
0.9.33.2 + gcc 4.5.4).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Practically speaking, MIPS has three useful ABIs:
* o32 is for 32-bits CPUs, or 64-bit CPUs running only a 32-bit subset
of the instruction set.
* n32 is for 64-bits CPUs only. It has 32-bits pointers and long
integers.
* n64 is for 64-bits CPUs only. It has 64-bits pointers and long
integers.
See http://www.linux-mips.org/wiki/MIPS_ABI_History and
http://www.linux-mips.org/wiki/WhatsWrongWithO32N32N64 for more
details.
So, this commit reworks the Buildroot MIPS support by:
* Add separate mips64/mips64el top-level architectures.
* Renaming the n32 ABI option to BR2_MIPS_NABI32, for consistency
with BR2_MIPS_OABI32.
* Renaming the n64 ABI option to BR2_MIPS_NABI64, for consistency
with BR2_MIPS_OABI32.
* Make the n32 and n64 ABI selections select the BR2_ARCH_IS_64,
since those ABIs are valid on 64-bits CPUs only.
* Removing the o64 ABI, which is practicaly never used.
* Removing the "none" ABI, which really doesn't make sense.
* Introduce the mips64 and mips64el architecture names when a 64-bits
MIPS ABI is choosen. This will fix build issue like
http://autobuild.buildroot.org/results/9b8c5ea86c953a89e85e7b67e9221de41773f652/build-end.log
where gmp was confused by the fact of having a 32 bits architecture
(detected by the mips- architecture part of the tuple) but 64 bits
integer size when compiling.
* Adjust the uclibc.mk logic to support the new mips64/mips64el
architecture names, and take into account the renaming of the ABI
options.
This has been build tested by generating Buildroot toolchains and
compiling a few packages for MIPS o32, MIPS n32 and MIPS n64.
This work is originally based on prior work done by Gustavo Zacarias.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The -fPIC breaks the purgatory of kexec (= the code that passes command-line
arguments to the kernel): kexec doesn't know how to handle the GOT and PLT
relocation entries.
There is also no reason at all to pass -fPIC. Shared libraries that require
it will add it to their local Makefiles, and normal executables have no
business with -fPIC (plus it adds overhead...).
The -fPIC was added by Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
in commit 8027784c. That commit adds sysroot parameters to CFLAGS.
There is no explanation why -fPIC is also added for x86_64.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When BR2_JLEVEL is 0, set PARALLEL_JOBS to double the number of CPUs
detected. This allows one to more or less fully utilize the host
system without manually tuning the configuration.
Also make 0 the default value for BR2_JLEVEL.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_JLEVEL currently is expanded directly in $(MAKE), and used in
invocations of other build software (e.g. ct-ng). However, we are
going to allow "0" to be a meaningful value for BR2_JLEVEL, which
won't work for these uses. Given that it is not permissible to modify
BR2_-prefixed variables in Makefiles, we need an intermediate
variable.
Define PARALLEL_JOBS to $(BR2_JLEVEL), and use the former in MAKE's
definition. Uses of BR2_JLEVEL throughout the rest of the tree to be
adjusted similarly in follow-up patches.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of providing two variables, make GNU_TARGET_NAME give the real
target name, and remove REAL_GNU_TARGET_NAME altogether.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Re-integrate in gcc-uclibc-4.x.mk things from
toolchain/gcc/Makefile.in that were completely gcc-specific. There was
no reason to pull that when building with other backends than the
internal one.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Some packages don't automatically enable IPv6 support if not configured
with --disable-ipv6, or use AC_TRY_RUN which doesn't work when cross
compiling (like curl), so explicitly configure with --enable-ipv6.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A host package that uses AUTORECONF (such as host-libglib2)
may end up running './config.status --recheck'. This will
call the configure script with the environment variables
set in HOST_MAKE_ENV. If PKG_CONFIG_SYSROOT_DIR is missing
this will cause the hardcoded sysroot dir take effect leading
to wrong paths.
See commit 22acade2ec which works around this problem by
fiddling with the generated .pc file. This commit becomes
obsolete with this fix.
Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add the ability for buildroot to build an SPE ABI enabled toolchain.
This is mandatory for e500v1/v2 cores since they don't support classic
FPU mode as the e500mc does.
Useful for Freescale's PowerQUICC III and single/dual-core QorIQ
line of processors.
The new TARGET_ABI variable is used rather than TARGET_CFLAGS for
uclibc's UCLIBC_EXTRA_CFLAGS to avoid breakish CFLAGS leaking in, a
good example being -mthumb for ARM.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Allow the user to specify additional options for the target LDFLAGS.
I use this to pass the -te500v2 option to the linker, when using the
CodeSourcery toolchain for PowerPC. This chooses the correct CRT for e500 hard
float. Otherwise I get errors like
undefined reference to `_save32gpr_31'
undefined reference to `_rest32gpr_31_x'
at final link time.
[Peter: fixup, use qstrip]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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>
Now that we use a wrapper for external toolchains (and internal ones
default to the correct setting), we no longer need to explicitly pass
sysroot/march/mtune/mabi/floating point mode in TARGET_CFLAGS.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add a simple toolchain wrapper for external toolchains, which forces the
correct sysroot/march/mtune/floating point options needed to use it
with buildroot.
With this in place the external toolchain behaves similar to the internal
ones, and the special handling can be removed. This also means that the
toolchain is usable outside buildroot without having to pass any special
compiler flags.
Also adjust the downloadable external toolchain support to install under
HOST_DIR so it can be used after the temporary build files are removed.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 7e3e8ec040 (CFLAGS/LDFLAGS: don't add -I / -L args for STAGING_DIR)
exposed a lingering libtool problem.
Unless instructed otherwise (using -L) libtool will search its built in
system path for libraries, and use those instead if found. The default
search path is '/usr/lib, /lib, /usr/local/lib', which is no good for
cross compilation.
Fix it by setting the system search path to the empty string, effectively
disabling this feature.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Now that we use sysroot for all toolchains, the explicit -I / -L arguments
in CFLAGS / LDFLAGS aren't needed anymore (And having them makes the build
quite noisy for certain packages as STAGING_DIR/include normally doesn't
exist).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Only prefix the external toolchain calls with its absolute path if
BR2_TOOLCHAIN_EXTERNAL_PATH is set, otherwise just assume it will
be available in the path.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A few packages (like xlib_xtrans) install their .pc files here, and
upstream pkg-config defaults to searching both /usr/lib/pkgconfig and
/usr/share/pkgconfig, so add it as well.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Similar to the --with-pc-path option. It works just like the existing
PKG_CONFIG_SYSROOT_DIR environment variable, but compiled in.
The environment variable overrides this default setting if set.
This way we don't need to pass PKG_CONFIG_SYSROOT_DIR in the environment
when building for the target, and it is easier to reuse pkg-config outside
BR (E.G. for the SDK) without having to setup special environment
variables.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The CMAKETARGETS infrastructure makes adding CMake-based packages to
Buildroot easy. It uses the same set of variables as the autotools
infrastructure, except for autoreconf and libtool stuff which is not
needed. Usage: just call CMAKETARGETS instead of AUTOTARGETS.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A CMake toolchain-file makes it easy to develop CMake-based packages
outside of Buildroot. Just give the toolchain-file to CMake via the
-DCMAKE_TOOLCHAIN_FILE=... option.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As pointed out on the list, using sysroot rather than sys-root is less
confusing, as this is how it is referred to in the GCC manual.
So rather than changing BR, patch ct-ng to use sysroot instead.
The next ct-ng release will use 'sysroot' as well by default.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Simplifies code and helps us when we add SDK support in the future.
With this we no longer need to copy headers/libraries to STAGING_DIR either.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The name of the sysroot directory is arbitrary, but as ct-ng uses sys-root,
let's use that as well for consistency.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Convert binutils to a proper autotargets package
* Add version 2.21 and drop version 2.17
* Hook up packaged binutils for target gcc
* Build tools are on HOST_DIR now so change it
* Move cross/host gcc to HOST_DIR
* Drop kludge from commit 3c77bab2ee
This is fixed in the next commit "gcc: install copies of libgcc,
libstdc++ and libgcj to the sysroot" - tested for arm & x86_64
targets.
* TARGET_CROSS now pointed to HOST_DIR too
[Peter: Config.in tweaks]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Remove VIS optimization, it's for sparc64 and it's gone.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Drop the BR2_STAGING_DIR option
* Hardcode STAGING_DIR to $(HOST_DIR)/usr/TUPLE/sysroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Convert sstrip to a proper gentargets package
* Use openwrt svn version, it's basically the same one we used
* Change the hooks from old toolchain/sstrip to new package/sstrip
* Drop the old toolchain/sstrip directory
* sstrip for the target is now in Package -> Development
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of having BR2_GCC_CROSS_CXX and BR2_INSTALL_LIBSTDCPP, with
BR2_GCC_CROSS_CXX not being visible (and therefore being useless),
let's just keep BR2_INSTALL_LIBSTDCPP to enable C++ in the toolchain
and install C++ libraries on the target.
We also take that opportunity to make BR2_INSTALL_LIBSTDCPP an hidden
option, which is selected by an option in Buildroot toolchain support
or an option in External toolchain support, just as we did for other
toolchain features.
Some work definitely remains to be done :
- The name BR2_INSTALL_LIBSTDCPP is ugly, but we keep it for the
moment in order to avoid changing all packages.
- We should clarify the other language-related options (Fortran,
Java, Objective-C, etc.).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
