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>
DirectFB SVG support rely on Cairo and Cairo depends on DirectFB.
Since Cairo DirectFB backend is marked as experimental, this patch choose to
disable this backend when DirectFB SVG support is enable.
In add, this patch may solve some tricky situations between DirectFB and Cairo
(see http://sysmic.org/~jezz/results/c2f11fc0) and improve build reproducibility.
[Peter: propagate atomics dependency, needs libsvg-cairo, add cairo includes]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/dfc51d2b:
.../ltp-testsuite-20140115/lib/tests/tst_checkpoint_child.c:40: undefined reference to `_fork'
collect2: ld returned 1 exit status
make[3]: *** [tst_checkpoint_child] Error 1
make[3]: *** Waiting for unfinished jobs....
/tmp/ccF9CQQa.o: In function `main':
.../ltp-testsuite-20140115/lib/tests/tst_checkpoint_parent.c:40: undefined reference to `_fork'
collect2: ld returned 1 exit status
make[3]: *** [tst_checkpoint_parent] Error 1
/tmp/ccwCGpYd.o: In function `main':
.../ltp-testsuite-20140115/lib/tests/tst_checkpoint_parent_exits.c:40: undefined reference to `_fork'
collect2: ld returned 1 exit status
make[3]: *** [tst_checkpoint_parent_exits] Error 1
/tmp/cc8TiB6d.o: In function `main':
.../ltp-testsuite-20140115/lib/tests/tst_process_state.c:43: undefined reference to `_fork'
collect2: ld returned 1 exit status
make[3]: *** [tst_process_state] Error 1
/tmp/ccrf7Gjb.o: In function `main':
.../ltp-testsuite-20140115/lib/tests/tst_checkpoint_child_exits.c:40: undefined reference to `_fork'
collect2: ld returned 1 exit status
[Peter: don't mention mmu dependency in comment]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/17f32103:
xfs_fsr.o: In function `fsrallfs':
/home/jezz/br-continuous/cfgs/45-bf609-bfin-uclibc-nommu-ext/build/xfsprogs-3.1.11/fsr/xfs_fsr.c:617: undefined reference to `_fork'
collect2: ld returned 1 exit status
madvise.o: In function `madvise_f':
/home/jezz/br-continuous/cfgs/45-bf609-bfin-uclibc-nommu-ext/build/xfsprogs-3.1.11/io/madvise.c:111: undefined reference to `_madvise'
mincore.o: In function `mincore_f':
/home/jezz/br-continuous/cfgs/45-bf609-bfin-uclibc-nommu-ext/build/xfsprogs-3.1.11/io/mincore.c:77: undefined reference to `_mincore'
collect2: ld returned 1 exit status
[Peter: don't mention mmu dependency in comment]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/53a729c3:
button.o: In function `_executeCommand':
./button.c:(.text+0x21be): undefined reference to `_fork'
main.o: In function `_get_pty':
./main.c:(.text+0xab0): undefined reference to `_getpt'
main.o: In function `_spawnXTerm':
./main.c:(.text+0x1030): undefined reference to `_fork'
misc.o: In function `_creat_as':
./misc.c:(.text+0x3a56): undefined reference to `_fork'
print.o: In function `_charToPrinter':
./print.c:(.text+0x1ee): undefined reference to `_fork'
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/e891eb7e:
dm.o: In function `_StartDisplay':
dm.c:(.text+0xd6e): undefined reference to `_fork'
server.o: In function `_StartServerOnce':
server.c:(.text+0x266): undefined reference to `_fork'
session.o: In function `_runAndWait':
session.c:(.text+0x67a): undefined reference to `_fork'
session.o: In function `_ManageSession':
session.c:(.text+0xa2a): undefined reference to `_fork'
collect2: ld returned 1 exit status
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/1a0bc183:
command.o: In function `__DoCommandToFileOrPipe':
command.c:(.text+0x35e): undefined reference to `_fork'
collect2: ld returned 1 exit status
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes: http://sysmic.org/~jezz/results/455f2788:
remote.o: In function `_remote_start':
remote.c:(.text+0x74): undefined reference to `_fork'
restart.o: In function `_Clone':
restart.c:(.text+0x5a8): undefined reference to `_fork'
restart.o: In function `_Restart':
restart.c:(.text+0xa44): undefined reference to `_fork'
collect2: ld returned 1 exit status
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/8b5af679:
xinit.o: In function `_main':
xinit.c:(.text+0x65e): undefined reference to `_fork'
xinit.c:(.text+0x7d4): undefined reference to `_fork'
collect2: ld returned 1 exit status
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://sysmic.org/~jezz/results/a9ec03bd:
xkbevd.o: In function `_main':
xkbevd.c:(.text+0x3ca): undefined reference to `_fork'
collect2: ld returned 1 exit status
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
... since BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SVGA is only available on x86.
Fix warnings like:
warning: (BR2_PACKAGE_XDRIVER_XF86_VIDEO_VMWARE) selects
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SVGA which has unmet direct dependencies
(BR2_PACKAGE_MESA3D && (BR2_i386 || BR2_x86_64))
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Due to a kconfig limitation, we can't select a no-prompt symbol that
gets its dependencies by being conditionally re-defined in one or more
if-blocks, like we currently do for BR2_ARCH_HAS_ATOMICS.
As a workaround to this issue, we just redefine that symbol in the arc
if-block, like we do for all other architectures, except that in the arc
case, the default value is conditional.
Reported-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
[yann.morin.1998@free.fr: indepently re-done a patch similar to the one
Thomas made on his own]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some libarchive tools, like bsdtar, builds statically by default
although libarchive itself is being built dynamically. We can force
those tools to build the same way as libarchive by using the right
configure options.
Fixes:
http://autobuild.buildroot.net/results/b8f/b8f7a29787ea1cc5c98e4cbd5f47f257f9b306f2/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
CVE-2014-3613 cookie leak with IP address as domain
CVE-2014-3620 cookie leak for TLDs
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
