The github release mechanism only supports .tar.gz, hence the ugly
GCC_UNPACK variable.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While the generic package handler checks for a directory with patches
before starting apply-patches.sh, this is not the case for gcc: the
script is called, even if there is no directory with patches. This results
into a build failure, as apply-patches exits with error code 1 if the
directory doesn't exist.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some Config.in(.host) files have constructs like:
config FOO_VERSION
string
default "1.0" if FOO_1_0
default "2.0" if FOO_2_0
default $FOO_CUSTOM_VERSION if FOO_CUSTOM
The dollar sign here is not needed and confusing, so can be removed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While the idea of skipping the intermediate gcc step seems to work
fine in most situations, it causes problems with the SSP
support. Until we can figure out a proper solution for this problem,
we need to revert back to the previous solution of a three stages
build.
This reverts commit 2babed4a50.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As discussed on the list. They have been broken for a long time, and are
not commonly used in embedded systems.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The mudflap library is only useful if one uses the -fmudflap gcc
option to do more checks on pointers/arrays. This commit adds an
option to enable/disable mudflap support at the gcc level. By default,
it is disabled, which saves a little bit of build time compared to the
default of gcc which consists in enabling mudflap support.
Since mudflap is now disabled by default, and ensured to never be enabled
on platforms where it is not available, some gcc.mk code that was used to
disable mudflap in problematic configurations can be removed.
Whether -fmudflap is used when building is left to the user.
[Peter: tweak commit text, fix white space]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The HOST_GCC_CONFIGURE_SYMLINK creates a symbolic link
$(@D)/build/configure -> $(@D)/configure for each build step of
gcc. However, it was only using 'ln -s' and not 'ln -sf', which was
causing problems when doing 'make host-gcc-final-reconfigure' for
example, because the configure commands (including this macro) are
being re-executed, but the symbolic link already exists.
Changing this symbolic link creation to 'ln -sf' fixes this problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Each stage of the gcc build needs to make a small dance before the
configuration step to create a build sub-directory and a symbolic link
to the configure script. The common gcc.mk had a
HOST_GCC_CONFIGURE_SYMLINK already used by the gcc-initial and
gcc-intermediate steps, but the gcc-final step wasn't using it.
This commit fixes this inconsistency, and therefore removes the
HOST_GCC_FINAL_CONFIGURE_SYMLINK macro.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The support for eglibc 2.17 was added to the internal toolchain
backend for 2013.08. This commit now adds glibc 2.18 support to the
internal toolchain backend.
Since the building procedure is very similar to the one of eglibc, we
have renamed the 'eglibc' package to 'glibc', and made it capable of
handling either glibc or eglibc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The option to enable C++ support was still located in
toolchain/toolchain-buildroot/Config.in.2, with misc other toolchain
options. It seems more logical to have this option with the other
options to select the languages supported by the cross-compiler, so we
move it next to the Fortran/Objective-C options in
package/gcc/Config.in.host.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit fixes the Objective-C support in the gcc package by making
sure that the runtime Objective-C library is properly installed to the
target.
It also takes this opportunity to slightly reword the Config.in option
help text to have a more meaningful explanation.
Finally, it fixes the gcc-final.mk code to use the correct
BR2_INSTALL_OBJC option rather than the non-existing
BR2_GCC_CROSS_OBJC option, to decide whether Objective-C support
should be enabled or not in the cross-compiler.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit fixes the Fortran support in the gcc package by making
sure that the runtime Fortran library is properly installed to the
target.
It also takes this opportunity to slightly reword the Config.in option
help text, to no longer mention gcc < 4.2 since they are no longer
supported in Buildroot, and to have a more meaningful explanation.
Finally, it fixes the gcc-final.mk code to use the correct
BR2_INSTALL_FORTRAN option rather than the non-existing
BR2_GCC_CROSS_FORTRAN option, to decide whether Fortran support should
be enabled or not in the cross-compiler.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When NPTL support was introduced, gcc required a three stages build
process. Since gcc 4.7, this is no longer necessary, and it is
possible to get back to a two stages build process. This patch takes
advantage of this, by doing a two stages build process when possible.
We introduce a few hidden kconfig options:
* BR2_GCC_VERSION_NEEDS_THREE_STAGE_BUILD, which is set by the gcc
Config.in logic to indicate that the compiler might need a three
stages build. Currently, all versions prior to 4.7.x are selecting
this kconfig option.
* BR2_TOOLCHAIN_LIBC_NEEDS_THREE_STAGE_BUILD, which indicates whether
the C library might need a three stages build. This is the case for
eglibc, and uClibc when NPTL is enabled.
* BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD finally is enabled when both
of the previous options are enabled. It indicates that a three
stages build is actually needed.
In addition to those options, the uClibc/gcc build logic is changed to
use only a two stages build process when possible.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add host-elf2flt to the gcc common dependencies so we get it built after
binutils but before gcc/uclibc since it's required for all packages and
in some uClibc configuration scenarios.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Make 3.82 no longer sort the result of wildcards (see
http://comments.gmane.org/gmane.comp.gnu.make.bugs/4260). This may break
build reproducibility.
This patch sort results of wildcards to ensure reproducibility.
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Fixes a build issue with the avr32 toolchain:
http://jenkins.free-electrons.com/job/buildroot/config=atngw100_defconfig/104/
Invalid configuration `MAKEINFO=missing': machine `MAKEINFO=missing' not
recognized
Instead pass it in the environment of ./configure, similar to how it was
done originally in 62322acb2c (toolchain/gcc: disable makeinfo).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The documentation of older GCC versions (E.G. 4.3.x) contain constructs
that are no longer accepted by recent (5.x) versions of makeinfo, breaking
the build.
The documentation isn't really needed, and takes up extra space/build time,
so work around it by disabling documentation, like we had before the
conversion of the toolchain to the package infrastructure.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since 5628776c4a
"toolchain-external: fix lib64 symlinks"
lib64 is a symlink to lib so there is no reason to copy the libraries
to lib64 anymore. This fixes multiple building problems
for buildroot toolchains:
[...]
mv: 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64/libuClibc-0.9.33.2.so'
and 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib/libuClibc-0.9.33.2.so'
are the same file
mv: 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64/libutil-0.9.33.2.so'
and 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib/libutil-0.9.33.2.so'
are the same file
mv: 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64/libutil.so.0'
and 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib/libutil.so.0'
are the same file
rmdir: failed to remove
'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64': Not a directory
[...]
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
It is not clear why 300-libstdc++-pic.patch pre-applied to
gcc-4.2.2-avr32-2.1.5 seems to have come from some older version
of gcc (as early as 4.0.3). This older patch incorrectly refers to
object files to be included in the library libstdc++_pic.a as *.o,
while their location seems to be in .libs/*.o (see the contents at
e.g. https://github.com/ZigFisher/Midge/blob/master/toolchain/gcc/4.0.3/300-libstdc%2B%2B-pic.patch ).
The same patch for gcc 4.1.0 refers to the files as .libs/*.o (see
https://github.com/ZigFisher/Midge/blob/master/toolchain/gcc/4.1.0/300-libstdc%2B%2B-pic.patch ).
This patch corrects rules in Makefile.in.
Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>
Acked-by: Simon Dawson <spdawson@gmail.com>
Tested-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libmudflap doesn't build for a thumb(1) toolchain so disable it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This fixes multiple issues, including:
- 'operand out of range' errors (due to defaulting to
medium calls instead of short calls)
- library dependencies that were not being found
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Until now, we were using the default ARM instruction set, as used by
the toolchain: the 32 bits ARM instruction set for the internal
backend, and for external toolchain, whatever default was chosen when
the toolchain was generated.
This commit adds support for the Thumb2 instruction set. To do so, it:
* provides a menuconfig choice between ARM and Thumb2. The choice is
only shown when Thumb2 is supported, i.e on ARMv7-A CPUs.
* passes the --with-mode={arm,thumb} option when building gcc in the
internal backend. This tells the compiler which type of
instructions it should generate.
* passes the m{arm,thumb} option in the external toolchain
wrapper. ARM and Thumb2 code can freely be mixed together, so the
fact that the C library has been built either ARM or Thumb2 and
that the rest of the code is built Thumb2 or ARM is not a problem.
[Peter: fix empty BR2_GCC_TARGET_MODE check]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When using eglibc, the ld-linux loader is installed as
ld-linux-armhf.so.3, but gcc 4.7.x was not yet updated, and generates
binaries that reference ld-linux.so.3. This was fixed starting with
gcc 4.8.x. In order to be able to use gcc 4.7, we create the
appropriate symbolic link.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The ARM EABIhf support was introduced in gcc 4.6.x, so versions
earlier than this one should not be used when EABIhf is selected.
The ARM VFPv4 support was introduced in gcc 4.5.x, so versions earlier
than this one should not be used when VFPv4 is used.
[Peter: drop OABI dependencies]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When refactoring the internal toolchain backend logic, the code was
changed to pass the custom configure options given through
BR2_EXTRA_GCC_CONFIG_OPTIONS only for the gcc final pass, with the
idea that we're only interested by user customization for the final
compiler.
However, the beaglebone_defconfig was passing --with-float=hard
--with-fpu=vfpv3-d16 as BR2_EXTRA_GCC_CONFIG_OPTIONS, and since the
refactoring, it was causing build failures of the beaglebone_defconfig
(with messages saying that Busybox is built to use VFP arguments, but
libc/libm are not). This is due to the fact that the gcc intermediate,
which is used to build the C library, wasn't built to generate hard
float, while the final compiler was generating hard float.
So, we get back to the original situation where the options in
BR2_EXTRA_GCC_CONFIG_OPTIONS are passed to all of the compiler
passes. Of course, the specific case of hard float will be fixed by
following patches in this area, but the idea still remains: the three
gcc should have the same options, if those options affected the ABI of
the generated code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 6b48b48034 ("add a know to enable/disable building a shared
libgcc"), from october 2006, isn't really as to why a
BR2_GCC_SHARED_LIBGCC option was needed. However, now that gcc has
been converted to the package infrastructure, it causes problems
because the host packages are always being passed --enable-shared
--disable-static, so re-adding --disable-shared on top of that break
things.
Moreover, our tests indicate that both a shared *and* a static version
of libgcc are built, and that linking dynamically and statically a
program that uses libgcc_s gives correct results: dynamically linked
against libgcc_s in the first case, statically linked in the second
case.
Therefore, it appears that this option is no longer necessary, and
removing it has the advantage of fixing the builds of
qemu_mips64_malta_defconfig and qemu_sparc_ss10_defconfig, both of
which had BR2_GCC_SHARED_LIBGCC not enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Using the newly introduced 'eglibc' package, this commit enables the
option of building a toolchain using the eglibc C library in the
Buildroot toolchain backend.
In details, this commit:
* Creates a choice to select uClibc or eglibc in the Buildroot
toolchain backend (in toolchain/toolchain-buildroot/Config.in), and
removes the fact that the Buildroot toolchain backend forcefully
enables uClibc (toolchain/Config.in).
* Creates a BUILDROOT_LIBC variables, which points to the package
implementing the C library (i.e either 'uclibc' or 'eglibc').
* Modifies the gcc-final and gcc-intermediate makefiles to use the
BUILDROOT_LIBC variable instead of hardcoding the use of uclibc.
* Ensures that TLS support is always enabled when building eglibc.
[Peter: fix commit text to refer to BUILDROOT_LIBC]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[Peter: update manual to match]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Several sub-directories of the gcc code base are in fact not needed
for the Buildroot build: libjava/, libgo/ and gcc/testsuite/ being the
biggest ones. Avoiding their extraction saves quite a bit of disk
space, and compensates a bit the fact that we now extract three times
the gcc source code.
This requires changing the 100-uclibc-conf.patch to no longer patch
files from the libjava/ directory, since this directory is no longer
extracted.
[Peter: add comment about why this is done]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
