Currently, the possibility to choose the floating point mode (32, xx or
64) is conditional on having a sufficiently recent gcc version.
Which means that the architecture selection depends on the gcc version.
But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.
Thus, we inverse the logic, to move the condition onto the software
side: whenever mfpxx is selected, we restrict the toolchain selection to
at least a gcc-5.
And now, the blind BR2_TOOLCHAIN_HAS_MFPXX_OPTION symbol is no longer
needed, so we get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-mfpxx option was added in gcc-5.1.0 so make sure that users cannot
select the "xx" fp32 mode when using toolchains that have a gcc older
than 5.1.0.
-mfp32 and -mfp64 were added in gcc-4.1.0, so given the older gcc
version we support in Buildroot (in the GCC_AT_LEAST options) is 4.3 we
don't need to do anything else for them.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-mnan option was added in gcc-4.9.0 so make sure that users cannot
select the NaN mode when using toolchains that have a gcc older
than 4.9.0, and also make sure that the -mnan option is not passed at
all to the toolchain-wrapper and target cflags.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that all packages have been migrated to the new gettext logic, we
can remove the BR2_NEEDS_GETTEXT and BR2_NEEDS_GETTEXT_IF_LOCALE
variables.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This new boolean is true if the toolchain provides a built-in
full-featured implementation of gettext (glibc), and false if only a
stub implementation is provided (uclibc, musl).
This will be used in follow-up commits to decide whether libintl needs
to be built by gettext or not.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As GCC 7 is now available in Buildroot, update the definition for
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 as the bug #64735 is fixed in GCC 7.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove upstream patches:
831-ARM-PR-target-70473-Reduce-size-of-Cortex-A8-automat.patch
870-xtensa-Fix-PR-target-78118.patch
871-xtensa-Fix-PR-target-78603.patch
890-fix-m68k-compile.patch:
1701058da9
892-libgcc-mkmap-symver-support-skip_underscore.patch:
6c8f362e1f
893-libgcc-config-bfin-use-the-generic-linker-version-in.patch:
966d046c08
894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch:
397d0e43ab
895-bfin-define-REENTRANT.patch:
da89a4dcdf
940-uclinux-enable-threads.patch:
b9ce54109e
941-mips-Add-support-for-mips-r6-musl.patch:
8371706509
Remove obsolete patches:
301-missing-execinfo_h.patch: boehm-gc removed from gcc sources:
baf7122876
830-arm_unbreak_armv4t.patch: SUBTARGET_CPU_DEFAULT removed:
ff3caa3ade
Add a new patch to allow to build gcc 7.1 without extracting gcc/testsuite
directory.
This new gcc version require a kernel patch [1] to avoid a build issue with
____ilog2_NaN symbol. The following kernel version contain contain already
this patch :
4.11, 4.10.6, 4.9.18, 4.4.57, 3.18.50 and 3.12.73.
To build a toolchain based on gcc 7 and uClibc-ng 1.0.24, the patch [2] is
required to avoid a build issue due to missing aligned_alloc() definition.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=474c90156c8dcc2fa815e6716cc9394d7930cb9c
[2] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/commit/?id=5b0f49037e8ea8500b05c8f31ee88529ccac4cee
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Theodore Ateba <tf.ateba@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
An autobuilder exception has been added to avoid testing qt gui module
with the CodeSourcery NiosII toolchain. This allow to remove the
BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 symbol.
This reverts commit 5dce3c05b5.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The rework done on commit
accba02a47 ("toolchain: add option for
toolchains affected by GCC PR libstdc++/64735") by me was wrong. The
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 option should be enabled when the bug is
present in the toolchain, not the opposite.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
exception_ptr, nested_exception, and future from libstdc++ are not
available for architectures not supporting always lock-free atomic ints
before GCC 7.
Bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
Fix available starting from GCC 7 (not yet released):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=244051
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
[Thomas:
- directly define the value where BR2_TOOLCHAIN_HAS_GCC_BUG_64735
rather than having additional patches touching affected architectures
Config.in files
- add a better comment above the Config.in option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though 4.8 is not released yet, some people may want to build a
system using the 4.8-rc kernel, and point to the kernel sources as the
kernel headers to use for the toolchain.
In order to make this possible, this commit adds support for specifying
4.8 as the kernel headers version, in both the internal and external
toolchain logic.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
[Thomas: remove support for 4.8 headers selection, and rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The options to purge locales and to generate locale data are currently
located in the toolchain menu. However, these options are not really
related to the toolchain per-se, they are more system-level
configuration options, much like the timezone selection option we
already have in the "System configuration" menu.
Therefore, it makes more sense to have the locale-related options in
the "System configuration" menu as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current list of locales to keep by default is "C en_US de fr". It
doesn't make much sense to keep "de" and "fr" more than any other
language. So let's keep only the "C" and "en_US" locales by default,
and leave it to the user to specify other locales to keep if needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current default is to keep all locales installed in
/usr/share/locale/. However, in practice, those locales take up a
significant amount of space, and most users do not need
locales. Therefore, it makes more sense to default to purging locales,
in order to keep only a few useful ones rather than keeping them all.
It helps in providing a small filesystem size by default, and still
allows advanced users who really need locales to tune their
configuration.
As an example, a very basic system with just util-linux enabled (not
even Busybox) weights 11 MB, including 6.4 MB of locales. With this new
default, the generated system is only 4.2 MB.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The cairo package fails to build on some architectures:
BR2_TOOLCHAIN_HAS_LIBATOMIC is enabled, but libatomic is in fact not
available.
This happens because the gcc logic in libatomic/configure.tgt does not
recognize "uclinux" as a valid OS part of the target tuple, and
therefore it does not build libatomic.
The "uclinux" part of the tuple is used by Buildroot when
BR2_BINFMT_FLAT=y, so we make BR2_TOOLCHAIN_HAS_LIBATOMIC enabled only
if !BR2_BINFMT_FLAT.
It is worth mentioning that support for the uclinux tuple could most
likely very easily be added to gcc: it could rely on the generic
"posix" implementation of libatomic, which uses pthread locks,
available on all architectures where thread support is available.
Fixes:
[arm] http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671
[m68k] http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: adjust dependency after analysis of the gcc code.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
uClibc-ng does not support PIE for some architectures as
arc and m68k. It isn't implemented in the static linking case, too.
With musl toolchains you might have static PIE support with little
patching of gcc. Static linking for GNU libc isn't enabled in
buildroot. Fixup any package using special treatment of PIE.
(grep -ir pie package/*/*.mk)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: use positive logic.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This symbol should be used in all packages requiring/testing for fortran
support.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This hidden symbol allow to know when libquadmath can be built and
installed.
Also, declaring this symbol in toolchain-common.in allows to use it in
both external and buildroot toolchain backend.
This will be needed for adding/improving the fortran support.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Trying to use __sync_fetch_and_add ends with a gcc ICE.
This fixes following autobuild failure, by actually disabling
the package for coldfire:
http://autobuild.buildroot.net/results/d719db11210d42501332586b4485ab0cc1e125dd/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds the support for gcc 6. This release allows to remove
a large number of our gcc patches, mainly thanks to the Xtensa and
musl related patches being merged upstream.
Patches kept with no changes:
100-uclibc-conf.patch
301-missing-execinfo_h.patch
810-arm-softfloat-libgcc.patch
830-arm_unbreak_armv4t.patch
840-microblaze-enable-dwarf-eh-support.patch
860-cilk-wchar.patch
890-fix-m68k-compile.patch
Patches dropped because they have been merged upstream, or were
already upstream backports:
120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
850-libstdcxx-uclibc-c99.patch (merged in a different form, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393)
870-xtensa-add-mauto-litpools-option.patch (upstream backport)
871-xtensa-reimplement-register-spilling.patch (upstream backport)
872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
874-xtensa-add-uclinux-support.patch (upstream backport)
900-libitm-fixes-for-musl-support.patch (upstream backport)
901-fixincludes-update-for-musl-support.patch (upstream backport)
902-unwind-fix-for-musl.patch (upstream backport)
903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
904-musl-libc-config.patch (upstream backport)
905-add-musl-support-to-gcc.patch (upstream backport)
905-add-musl-support-to-gcc.patch (upstream backport)
906-mips-musl-support.patch (upstream backport)
907-x86-musl-support.patch (upstream backport)
908-arm-musl-support.patch (upstream backport)
909-aarch64-musl-support.patch (upstream backport)
Successfully build-time and run-time tested with
qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Linux kernel doesn't even support i386 anymore, there is no NPTL
support for i386 and uClibc-ng only supports NPTL on x86, so there is
essentially no usable thread implementation. Most likely glibc and
musl also don't support i386 either. So it's time to remove the
support for this architecture variant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, we were assuming that whenever you have gcc 4.8, libatomic
is available. It turns out that this is not correct, since libatomic
will not be available if thread support is disabled in the toolchain.
Therefore, __atomic_*() intrinsics may not be available even if the
toolchain uses gcc 4.8.
To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
boolean, which indicates whether the toolchain has libatomic. It is
the case when you are using gcc >= 4.8 *and* thread support is
enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
BR2_TOOLCHAIN_HAS_ATOMIC.
As explained in the comment, on certain architectures, libatomic is
technically not needed to provide the __atomic_*() intrinsics since
they might be all built-in. However, since libatomic is only absent in
non-thread capable toolchains, it is not worth making things more
complex for such seldomly used configuration.
Note that we are introducing the intermediate
BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
own for certain packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option
to indicate whether the architecture supports atomic operations or
not. However, the reality of atomic operations support is much more
complicated and requires more than one option to be expressed
properly.
There are in fact two types of atomic built-ins provided by gcc:
(1) The __sync_*() family of functions, which have been in gcc for a
long time (probably gcc 4.1). They are available in variants
operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some
architectures implement a number of variants, some do not
implement any, some implement all of them.
They are now considered "legacy" by the gcc developers but are
nonetheless still being used by a significant number of userspace
libraries and applications.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
(2) The __atomic_*() family of functions, which have been introduced
in gcc 4.7. They have been introduced in order to support C++11
atomic operations. In gcc 4.8, they are available on all
architectures, either built-in or in the libatomic library part
of the gcc runtime (in which case the application needs to be
linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics
are only supported on certain architectures, since libatomic did
not exist at the time.
For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because
depending on the architecture, some variants may or may not be
available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the
variant is missing would cause a large number of packages to become
unavailable, even if they in fact use only more common variants
available on a large number of architectures. For this reason, we've
chosen to introduce four new Config.in options:
- BR2_TOOLCHAIN_HAS_SYNC_1
- BR2_TOOLCHAIN_HAS_SYNC_2
- BR2_TOOLCHAIN_HAS_SYNC_3
- BR2_TOOLCHAIN_HAS_SYNC_4
Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte
and 8-byte __sync_*() built-ins respectively.
For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if
the __atomic_*() built-ins are available. Note that it is up to the
package to link with -latomic when gcc is >= 4.8. Since __atomic_*()
intrinsics for all sizes are supported starting
We conducted a fairly large analysis about various architectures
supported by Buildroot, as well as with a number of different
toolchains, to check which combinations support which variant. To do,
we linked the following program with various toolchains:
int main(void)
{
uint8_t a;
uint16_t b;
uint32_t c;
uint64_t d;
__sync_fetch_and_add(&a, 3);
__sync_fetch_and_add(&b, 3);
__sync_fetch_and_add(&c, 3);
__sync_fetch_and_add(&d, 3);
__sync_val_compare_and_swap(&a, 1, 2);
__sync_val_compare_and_swap(&b, 1, 2);
__sync_val_compare_and_swap(&c, 1, 2);
__sync_val_compare_and_swap(&d, 1, 2);
__atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&b, &b, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&c, &c, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&d, &d, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
return 0;
}
And looked at which symbols were unresolved. For the __atomic_*()
ones, we tested with and without -latomic to see which variants are
built-in, which variants require libatomic. This testing effort has
led to the following results:
__sync __atomic gcc
1 2 4 8 1 2 4 8
ARC Y Y Y - Y Y Y L 4.8 [with BR2_ARC_ATOMIC_EXT]
ARC - - - - L L L L 4.8 [without BR2_ARC_ATOMIC_EXT]
ARM Y Y Y X Y Y Y Y 4.8, 4.7
ARM Y Y Y - 4.5
AArch64 Y Y Y Y Y Y Y Y 4.9, 5.1
Bfin - - Y - 4.3
i386 (i386) - - - - L L L L 4.9
i386 (i486..) Y Y Y - L L L L 4.9 [i486, c3, winchip2, winchip-c6]
i386 (> i586) Y Y Y Y L L L L 4.9
Microblaze - - Y - L L Y L 4.9
MIPS Y Y Y - Y Y Y L 4.9
MIPS64 Y Y Y Y Y Y Y Y 4.9
NIOS 2 Y Y Y - Y Y Y L 4.9, 5.2
PowerPC Y Y Y - Y Y Y L 4.9
SuperH Y Y Y - Y Y Y L 4.9
SPARC - - - - L L L L 4.9
SPARC64 Y Y Y Y Y Y Y Y 4.9
x86_64 Y Y Y Y Y Y Y Y 4.7, 4.9
Xtensa Y Y Y - Y Y Y Y 4.9
Notes:
* __atomic built-ins appeared in gcc 4.7, so for toolchais older than
that, the __atomic column is empty.
* Y means 'supported built-in'
* L means 'supported via linking to libatomic' (only for __atomic
functions)
* X indicates a very special case for 8 bytes __sync built-ins on
ARM. On ARMv7, there is no problem, starting from gcc 4.7, the
__sync built-in for 8 bytes integers is implemented, fully in
userspace. For cores < ARMv7, doing a 8 bytes atomic operation
requires help from the kernel. Unfortunately, the libgcc code
implementing this uses the __write() function to display an error,
and this function is internal to glibc. Therefore, if you're using
glibc everything is fine, but if you're using uClibc or musl, you
cannot link an application that uses 8 bytes __sync
operations. This has been fixed as part of gcc PR68095, merged in
the gcc 5 branch but not yet part of any gcc release.
* - means not supported
This commit only introduces the new options. Follow-up commits will
progressively change the packages using BR2_ARCH_HAS_ATOMICS to use
the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC
until the point where BR2_ARCH_HAS_ATOMICS can be removed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Quite some time ago, we added the options
BR2_TOOLCHAIN_HAS_GCC_BUG_58595 and BR2_TOOLCHAIN_HAS_GCC_BUG_58854 to
indicate if the toolchain was affected by those gcc bugs, which were
causing build failure with a number of packages.
With the recent change in the external toolchain logic to provide only
the latest version of each toolchain "family", all the toolchains
which were affected by those issues disappeared from Buildroot. Those
options are no longer being selected anywhere, and being blind
options, it means their value is always going to be "disabled".
Conquently, this commit removes those options completely, and updates
all the packages where they were used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds a number of hidden Config.in options, that will be
used to handle dependencies on the gcc version. We mimic the model
that was used for the kernel headers dependency mechanism.
These hidden options will be selected by the internal and external
toolchain backend logic respectively, in follow-up commits.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Instead of blacklisting which architectures support MMUs (mandatorily
or optionally), introduce two Kconfig options that are selected by each
architecture in each case.
This simplifies the logic in BR2_USE_MMU.
Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's no longer used so farewell.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove BR2_INET_IPV6 select for predefined external toolchains.
Remove the (non)IPv6 option prompt since it's now mandatory.
And force the toolchain check now that internal uclibc is always built
with IPv6 support and external non-IPv6 toolchains are disallowed.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's now unused so remove it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This will allow us to remove largefile handling in the tree without
breaking things while doing so.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-pipe is causing some build failures in Linux kernel >= 3.17.
Also, nowadays, using -pipe does not gain as much as it used to back in
the days:
Measurements made with a 3.16.7 Linux kernel:
make linux-depends
time sh -c 'make linux-build >/dev/null 2>&1'
Without -pipe:
716.32user 54.44system 3:42.12elapsed 346%CPU
721.22user 54.47system 3:41.81elapsed 349%CPU
722.44user 54.00system 3:42.13elapsed 349%CPU
721.03user 53.81system 3:41.92elapsed 349%CPU
713.21user 53.63system 3:40.51elapsed 347%CPU
706.67user 52.42system 3:38.40elapsed 347%CPU
714.40user 53.18system 3:40.16elapsed 348%CPU
706.01user 53.09system 3:37.87elapsed 348%CPU
705.98user 53.01system 3:38.03elapsed 348%CPU
714.17user 53.55system 3:39.98elapsed 348%CPU
Average: 3:40.29elapsed
With -pipe:
720.13user 53.90system 3:41.98elapsed 348%CPU
713.38user 53.69system 3:40.44elapsed 347%CPU
711.60user 52.81system 3:39.06elapsed 348%CPU
708.66user 53.09system 3:38.59elapsed 348%CPU
711.76user 53.00system 3:38.48elapsed 350%CPU
717.85user 53.97system 3:41.77elapsed 348%CPU
716.77user 53.77system 3:40.91elapsed 348%CPU
717.48user 53.65system 3:41.24elapsed 348%CPU
721.44user 55.67system 3:43.45elapsed 347%CPU
724.61user 55.63system 3:43.35elapsed 349%CPU
Average: 3:40.93elapsed
The delta is well in the measurement noise.
Just get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
