Do the edit of conf-* files only when 'cc' appears at the beginning of line,
i.e. the files has not been edited. Otherwise, the 'cc' part of the cross
toolchain gets expanded, leading to the following error on 'make
memtester-rebuild':
./compile: line 3: /home/baruch/git/buildroot/output/host/usr/bin/i686-pc-linux-gnu-g/home/baruch/git/buildroot/output/host/usr/bin/i686-pc-linux-gnu-gcc: No such file or directory
Makefile:82: recipe for target 'memtester.o' failed
make[1]: *** [memtester.o] Error 127
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order to comply with naming policy, fix celt.mk filename.
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Only use ccache prefix in QMAKE_CC and QMAKE_CXX since the build system is
broken when QMAKE_AR contains a space character.
Remove the upstreamed uClibc patch.
Signed-off-by: Fatih Aşıcı <fatih.asici@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Surprisingly long-standing issue with conflicting /bin/hostname
installs. Reported as early as November 2005 by Joseph Dupre.
All together at one point or another there are at least 4 possible
sources of /bin/hostname:
busybox
util-linux
coreutils
net-tools
Buildroot depends on the -F flag being available in the default
/etc/inittab. Out of the 4 listed projects only net-tools and buildroot
for sure support the -F flag. I'm a little unclear on util-linux as it
has been removed entirely (in favor of net-tools) for some time.
As of coreutils 6.9.90 (2007-12-01), coreutils does not install its
/bin/hostname by default. The following commit reenabled its build:
d6e58cb coreutils: fixed missing hostname (Sep 2010)
This was done to fix a build error in coreutils regarding help2man. A
later patch:
30c5105 coreutils: bump to version 8.21
disabled the help2man functionality entirely but left hostname being
installed.
On a very related note, net-tools now contains an obsolete check to add
util-linux as a dependency to force it to build first (so that net-tools
ends up with /bin/hostname).
This patch fixes both of these issues so that hostname always comes from
one of two places:
busybox
net-tools
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Co-authored-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CONFIG_SITE is now a part of pkg-autotools infrastructure.
This reverts commit 85448febb3.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On fedora 20 64bits host, the file /usr/share/config.site contains
a fix for installing libraries into /lib/lib64 on 64bits systems
that redefine libdir in the generated Makefile
For safety and avoid the bug #7262 [1], disable loading this file
when running the configure script for the target and the host.
Note: configure scripts generated with autoconf < 2.65 will source
the /dev/null and print this line:
"configure: loading site script /dev/null"
[1]: https://bugs.busybox.net/show_bug.cgi?id=7262
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Without the override, systemwide ncurses6-config can be found instead
of ncurses5-config from staging.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This version adds support for installing important header files to
<staging>/usr/include/breakpad. It's no longer necessary to include the
whole breakpad source tree when building applications using libbreakpad.a.
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After switching to a two stage gcc solution, there is no longer a need
to do weird things in the uclibc build. We can greatly simplify
UCLIBC_CONFIGURE_CMDS to only do the configuration, and let the
existing UCLIBC_BUILD_CMDS do the build. Note that we have to build
the headers before starting the C library build, otherwise there is a
build failure (probably a uClibc bug).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After switching to a two stage gcc solution, there is no longer a need
to do weird things in the glibc build. We can greatly simplify
GLIBC_CONFIGURE_CMDS to only do the configuration, and let the
existing GLIBC_BUILD_CMDS do the build.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After switching to a two stage gcc solution, there is no longer a need
to do weird things in the musl build, with certain things being done
twice (MUSL_CONFIGURE_CALL). Now the MUSL_CONFIGURE_CMDS variable only
does the configuration, and the MUSL_BUILD_CMDS only does the build,
as it should be.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that we have switched to a two steps gcc build process that uses
only gcc-initial and gcc-final, we can get rid of the gcc-intermediate
package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the internal toolchain backend does a three stage gcc
build, with the following sequence of builds:
- build gcc-initial
- configure libc, install headers and start files
- build gcc-intermediate
- build libc
- build gcc-final
However, it turns out that this is not necessary, and only a two stage
gcc build is needed. At some point, it was believed that a three stage
gcc build was needed for NPTL based toolchains with old gcc versions,
but even a gcc 4.4 build with a NPTL toolchain works fine.
So, this commit switches the internal toolchain backend to use a two
stage gcc build: just gcc-initial and gcc-final. It does so by:
* Removing the custom dependency of all C libraries build step to
host-gcc-intermediate. Now the C library packages simply have to
depend on host-gcc-initial as a normal dependency (which they
already do), and that's it.
* Build and install both gcc *and* libgcc in
host-gcc-initial. Previously, only gcc was built and installed in
host-gcc-initial. libgcc was only done in host-gcc-intermediate,
but now we need libgcc to build the C library.
* Pass appropriate environment variables to get SSP (Stack Smashing
Protection) to work properly:
- Tell the compiler that the libc will provide the SSP support, by
passing gcc_cv_libc_provides_ssp=yes. In Buildroot, we have
chosen to use the SSP support from the C library instead of the
SSP support from the compiler (this is not changed by this patch
series, it was already the case).
- Tell glibc to *not* build its own programs with SSP support. The
issue is that if glibc detects that the compiler supports
-fstack-protector, then glibc uses it to build a few things with
SSP. However, at this point, the support is not complete (we
only have host-gcc-initial, and the C library is not completely
built). So, we pass libc_cv_ssp=no to tell the C library to not
use SSP support itself. Note that this is not a big loss: only a
few parts of the C library were built with -fstack-protector,
not the entire library.
* A special change is needed for ARC, because its libgcc depends on
the C library, which breaks building libgcc in
host-gcc-initial. This looks like a bug in the ARC compiler, as it
does not obey the inhibit_libc variable which tells the compiler
build process to *not* enable things that depend on the C
library. So for now, in host-gcc-initial, we simply disable the
build of libgmon.a for ARC. It's going to be built as part of
host-gcc-final, so the final compiler will have gmon support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The elfutils package provides a more recent version of the
libelf. Some packages such as ltrace need this more recent
version. Having two packages providing the same library leads to some
conflicts or dependency problems. For instance at the end we had only
one libelf.a when the 2 packages were selected.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The elfutils package provides a more recent version of the libelf, so
let's use it. It will allow to remove the libelf package and to avoid
conflicts with two packages providing the same library.
[Peter: adjust toolchain options comment to match]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The elfutils package provides a more recent version of the libelf, so
let's use it. It will allow to remove the libelf package and to avoid
conflicts with two packages providing the same library.
[Peter: adjust toolchain options comment to match]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The libelf is currently provided by 2 packages libelf and
elfutils. The first package provides an old version of the libelf
which is no more compatible with a recent version of ltrace. This
patch removes the dependency on the libelf package and only keep the
elfuils package which provides the accurate version of libelf for
ltrace.
It will also allow to remove the libelf package and to avoid conflicts
with two packages providing the same library.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently procps-ng binaries are installed under $(TARGET_DIR)/usr/usr
instead of $(TARGET_DIR)/usr, which would be the expected. This is
caused because the default value of the --exec-prefix configure option
is /usr, and Buildroot always adds --prefix=/usr to the configure
option. We fix this by setting --exec-prefix to an empty value.
At the same time we make sure the procps-ng binaries have precedence
over the busybox ones.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
coreutils configure script needs to know whether /proc/uptime is
available, but this is not possible in a cross-compilation
context. This leads to an uptime program that fails to work on the
target, as it has been compiled without /proc/uptime reading support.
This commit fixes that by telling coreutils at configure time that
/proc/uptime will be available on the target (which seems to be a
reasonable assumption on Linux systems).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: David Bachelart <david.bachelart@bbright.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For use-cases in which performance is more important than data integrity.
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
New package: openvmtools
[Peter: add patch to fix compilation against modern glib versions]
Signed-off-by: Karoly Kasza <kaszak@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If openssl devfiles are installed in the host the automatic lookup might
find that and cause issues.
So be explicit on the directory to avoid a search and patch the
directory logic since it's got a bug. Fixes:
http://autobuild.buildroot.net/results/5dd/5ddc8636d6555851f692c0c21f583df235340b19/
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The configure script finds the "howmany" macro, but some of the sources
using it do not include the required <sys/param.h> header.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A change introduced in strace-4.9 makes it incompatible with MIPS
architecture when using a uClibc toolchain. This is the failure:
signal.c: In function 'printsiginfo':
signal.c:453:9: error: 'siginfo_t' has no member named 'si_timerid'
sip->si_timerid, sip->si_overrun);
^
signal.c:453:26: error: 'siginfo_t' has no member named 'si_overrun'
sip->si_timerid, sip->si_overrun);
uClibc needs to be patched in order to fix this problem. In the meantime
we disable strace for MIPS when using a uClibc toolchain.
Fixes:
http://autobuild.buildroot.net/results/91c/91c0413e755c365332bc15d1d69ab3d6160ae78c/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It's not supported and the build breaks.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Adds ipmitool, a command-line interface to IPMI-enabled devices.
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our libsvg-cairo package doesn't have any dependency on X, and the
source code doesn't seem to be using X. However, the configure script
checks for X headers and libraries. If they are found on the host,
/usr/lib and /usr/include get added to the library/header paths
causing weird build failures. This commit should fix this problem by
explicitly disabling the X support.
Should fix:
http://autobuild.buildroot.org/results/d0f/d0fc233bb97c2ea18344746a5b7c63c8de65330a/http://autobuild.buildroot.org/results/0b3/0b3fb2ee9916aa265df5b6e4f04f6dfa25d1fc84/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: drop unused IEEE part as suggested by Baruch]
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The file containing the license for lua 5.1 was removed and the license
text was added to the readme in 5.2.
[Peter: swap 5.1/5.2 logic]
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libffi depends on pthreads.
Python depends on libffi (it can provide a builtin libffi, but also depends on
pthreads). Thus this patch also disable Python support if toolchain is compiled
w/o treads support.
Fixes http://sysmic.org/~jezz/results/204099dd:
../src/closures.c:119:21: fatal error: pthread.h: No such file or directory
[Peter: fix comment dependencies, add python3]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>