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>
Instead of letting the user define all the details of his external
toolchain, we define a set of profiles for well-known external
toolchains (CodeSourcery ones only at the moment, can easily be
extended with other toolchains).
Once a profile has been choosen, the user is offered the choice of
either letting Buildroot download and install the external toolchain,
or (as before) to tell Buildroot where the toolchain is installed on
the system.
We of course provide a "custom profile", through which the user can
configure Buildroot to use a custom external toolchain for which no
profile is available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* ccache is now a normal package (both for the host and the target).
* ccache option is now part of the "Build options" menu. It will
automatically build ccache for the host before building anything,
and will use it to cache builds for both host compilations and
target compilations.
* bump ccache to 3.1.3
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When sstrip is selected it tries to strip kernel modules too.
Unfortunately this fails with a "unrecognized program segment header
size" error thus interrupting the build process.
We introduce a new $(KSTRIPCMD) strip command for this, being a regular
strip when sstrip is selected and an empty stub when not stripping.
At the same time get rid of the REMOVE_SECTION_* variables, as they are
only used once.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Closes#2857
The OBJDUMP was missing from TARGET_CONFIGURE_OPTS, this patch adds it
to the proper place in package/Makefile.in.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Default HOST_CFLAGS to -O2, so host tools (like the cross compiler) are
built with optimization by default.
Based on a patch by Will Newton <will.newton@gmail.com>.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
And all the infrastructure surrounding it. A broken sed implementation
is quite rare nowadays, as seen by the fact that the current host-sed
support has been broken for a while, so just get rid of it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The current computation of REAL_GNU_TARGET_NAME is incorrect for
non-ARM glibc platforms because it generates something such as
mipsel-unknown-linux- as the REAL_GNU_TARGET_NAME.
So we correct this by :
* Adding "gnu" in the suffix when glibc is used, so that in the
previous case we will have mipsel-unknown-linux-gnu
* Improving the ARM_EABI code to correctly append "eabi" when glibc
is selected, so that we have arm-unknown-linux-gnueabi, and to
append "gnueabi" when uclibc is selected, so that we have
arm-unknown-linux-uclibcgnueabi. The little trick here is that LIBC
and ABI aren't completely orthogonal on ARM.
This fixes problems such as :
checking host system type... Invalid configuration
`mipsel-unknown-linux-': machine `mipsel-unknown-linux' not recognized
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit ed0d45fdd (Choose host/target ldconfig based on availability)
added a runtime check for a cross-ldconfig being available.
Unfortunately this checks runs too early (at package/Makefile.in parsing
time), so it always fails when using an internal toolchain as ldconfig
isn't built yet.
Fix it by moving the check to the only place it is used (target-finalize).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Decide whether to use the host or target ldconfig based on an
availability check instead of internal/external toolchain selection. An
external toolchain may very well provide an ldconfig while the host's
one may fail.
External toolchain generated by Gentoo crossdev:
$ LC_ALL=C i686-pc-linux-uclibc-ldconfig -r output/target/; echo $?
i686-pc-linux-uclibc-ldconfig: skipping /usr/lib: No such file or directory
0
vs. the host (x86_64-pc-linux-gnu) version:
$ LC_ALL=C /sbin/ldconfig -r output/target/; echo $?
/sbin/ldconfig: Can't open configuration file
output/target/etc/ld.so.conf: No such file or directory
/sbin/ldconfig: Can't open cache file /var/cache/ldconfig/aux-cache
: No such file or directory
1
Signed-off-by: Malte Starostik <m-starostik@versanet.de>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
TARGET_CONFIGURE_ENV defines CFLAGS, LDFLAGS, CXXFLAGS and FCFLAGS,
separatly from all other variables that are part of
TARGET_CONFIGURE_OPTS. This is useless and not consistent with the
HOST_CONFIGURE_ variables, therefore we merge TARGET_CONFIGURE_ENV
into TARGET_CONFIGURE_OPTS and fix the few users of
TARGET_CONFIGURE_ENV.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
These shouldn't be needed. Even when the cross-compiler is in
$(STAGING_DIR)/usr/bin, we anyway use an absolute path for TARGET_CC,
TARGET_LD and al.
Not having $(STAGING_DIR)/{usr/bin,bin} in the PATH will avoid having
Buildroot trying to run target binaries.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The definition of CC, LD, GCC, CPP, CXX and FC shouldn't contain the
CFLAGS/LDFLAGS/CXXFLAGS, those should be passed through the
appropriate variables.
However, the --sysroot option is a particular case here: it needs to
be part of the CC/LD/GCC/etc. definitions otherwise libtool strips it
from the CFLAGS/LDFLAGS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
