Commit Graph

13 Commits

Author SHA1 Message Date
Thomas Petazzoni
c5c9d0fe1d gcc/gcc-initial: fix build of the AVR32 toolchain
Since we switched to a two stage gcc build process, the AVR32
toolchain stopped building. This is because with such an old gcc
version, we cannot use the all-target-libgcc and install-target-libgcc
targets.

Before the two stage gcc, libgcc was only built in gcc-intermediate,
which carried a similar logic. This commit basically restores in
gcc-initial the logic that used to be in gcc-intermediate, which
consists in using the all-target-libcc and install-target-libgcc
targets only for gcc versions others than the AVR32 one.

Using the BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE option has a way of
distinguishing the old AVR32 compiler from the other gcc versions is a
bit ugly, but it's what was done in gcc-intermediate before. And since
the AVR32 support is due to go away at some point in the hopefully
near future, we don't care that much.

This will fix the build of the two AVR32 defconfig that have been
constantly failing since switching to the two stage gcc process.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-09 15:27:31 +02:00
Thomas De Schampheleire
f268f7131b .mk files: bulk aligment and whitespace cleanup of assignments
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.

This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.

Alignment of line continuation characters (\) is kept as-is.

The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'

Brief explanation of this command:
    ^\([A-Z0-9a-z_]\+\)     a regular variable at the beginning of the line
    \([?:+]\?=\)            any assignment character =, :=, ?=, +=
    \([^\\]\+\)             any string not containing a line continuation
    \([^\\ \t]\+\s*\\\)     string, optional whitespace, followed by a
                            line continuation character
    \(\s*\\\)               optional whitespace, followed by a line
                            continuation character

Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.

This expression was tested on following test text: (initial tab not
included)

	FOO     = spaces before
	FOO     =   spaces before and after
	FOO	= tab before
	FOO	  = tab and spaces before
	FOO =	tab after
	FOO =	   tab and spaces after
	FOO =   	spaces and tab after
	FOO =    \
	FOO = bar \
	FOO = bar space    \
	FOO   =		   \
	GENIMAGE_DEPENDENCIES   = host-pkgconf libconfuse
	FOO     += spaces before
	FOO     ?=   spaces before and after
	FOO     :=
	FOO     =
	FOO	=
	FOO	  =
	FOO =
	   $(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
	AT91BOOTSTRAP3_DEFCONFIG = \
	AXEL_DISABLE_I18N=--i18n=0

After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
  expression leaves the number of whitespace between the value and line
  continuation character intact, but the whitespace before that could have
  changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
  actually makes the code more readable.

Finally, the end result was manually reviewed.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-07 15:00:28 +02:00
Thomas De Schampheleire
aaffd209fa packages: rename FOO_CONF_OPT into FOO_CONF_OPTS
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.

Sed command used:
   find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-04 18:54:16 +02:00
Thomas De Schampheleire
b199343034 packages: rename FOO_INSTALL_OPT into FOO_INSTALL_OPTS
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_INSTALL_OPT.

Sed command used:
   find * -type f | xargs sed -i 's#_INSTALL_OPT\>#&S#g'

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-04 18:47:37 +02:00
Thomas De Schampheleire
0518a98ac3 packages: rename FOO_MAKE_OPT into FOO_MAKE_OPTS
While the autotools infrastructure was using FOO_MAKE_OPT, generic packages
were typically using FOO_MAKE_OPTS. This inconsistency becomes a problem
when a new infrastructure is introduced that wants to make use of
FOO_MAKE_OPT(S), and can live alongside either generic-package or
autotools-package. The new infrastructure will have to choose between either
OPT or OPTS, and thus rule out transparent usage by respectively generic
packages or generic packages. An example of such an infrastructure is
kconfig-package, which provides kconfig-related make targets.

The OPTS variant is more logical, as there are typically multiple options.

This patch renames all occurrences of FOO_MAKE_OPT in FOO_MAKE_OPTS.
Sed command used:
    find * -type f | xargs sed -i 's#_MAKE_OPT\>#&S#g'

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-04 15:07:23 +02:00
Thomas Petazzoni
6063a8fbcf toolchain: switch to a two stage gcc build
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>
2014-09-14 23:20:23 +02:00
Max Filippov
a957e1b265 gcc: fix xtensa overlay application
gcc build scripts use wrong variable name to specify xtensa overlay
application command. As a result gcc is built with the default overlay,
which leads to obscure failures later in the build process.

xtensa toolchain needs an additional configuration for a specific core
variant we're building for. This configuration is called 'overlay' and
is an archive with files for binutils, gcc and gdb that replace
corresponding files in toolchain components.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-27 09:07:27 +01:00
Thomas Petazzoni
ebc8193363 Revert "toolchain-internal: skip gcc-intermediate when possible"
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>
2013-10-04 08:58:08 +02:00
Thomas Petazzoni
2babed4a50 toolchain-internal: skip gcc-intermediate when possible
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>
2013-09-15 22:50:20 +02:00
Peter Korsgaard
5128cc6602 gcc: pass MAKEINFO=missing in the environment rather than as a ./configure arg
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>
2013-09-04 16:22:30 +02:00
Thomas Petazzoni
63c8887501 gcc: use BR2_EXTRA_GCC_CONFIG_OPTIONS in gcc-initial and gcc-intermediate
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>
2013-07-14 22:07:38 +02:00
Thomas Petazzoni
00e9b1e4f7 gcc-initial, gcc-intermediate, gcc-final: optimize extraction
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>
2013-07-03 23:37:23 +02:00
Thomas Petazzoni
3d616718b1 gcc-initial: new package
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-03 22:58:39 +02:00