Commit Graph

51 Commits

Author SHA1 Message Date
Yann E. MORIN
725f05967d package/gcc: use the Xtensa variables
... instead of re-computing them over-and-over-again.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-26 15:49:45 +02:00
Jérôme Pouiller
8087b02bdf toolchain/wrapper: fix 'reinstall'
toolchain-wrapper was not reinstalled. So rules toolchain-external-reinstall,
gcc-initial-reinstall, gcc-final-reinstall didn't work as expected.

In add, normalize variable name: s/TOOLCHAIN_BUILD_WRAPPER/TOOLCHAIN_WRAPPER_BUILD/

Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-24 23:02:33 +02:00
Arnout Vandecappelle
a7c13c1b28 gcc: remove deprecated 4.7.x
We will remove BR2_DEPRECATED, so remove this deprecated option.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 23:14:44 +02:00
Floris Bos
84c9130350 gcc/gcc-final: Disable libcilkrts when using static libs
Disable libcilkrts when building static, as there is no static version:
https://software.intel.com/en-us/articles/intel-cilk-plus-runtime-library-libcilkrts-can-only-be-linked-dynamically/

Fixes the following toolchain build error when building for i386 and
BR2_STATIC_LIBS=y + BR2_TOOLCHAIN_BUILDROOT_CXX=y is set:

../../../libcilkrts/runtime/sysdep-unix.c:603:19:
fatal error: dlfcn.h: No such file or directory

Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-08 21:55:01 +02:00
Waldemar Brodkorb
0d8a05c38e bfin: fix issues with internal toolchain, re-enable C++ support
The three patches allow to compile applications using TLS emulation from
libgcc or C++ applications.

The patches 892-libgcc-mkmap-symver-support-skip_underscore.patch and
893-libgcc-config-bfin-use-the-generic-linker-version-in.patch fixes how
libgcc is generated, by making the necessary libgcc symbols declared
"GLOBAL", and therefore visible outside of libgcc. This fixes a large
number of undefined reference issues (for either C++ applications or
applications using TLS emulation). This was reported as gcc PR74748.

The patch 894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch
allows to build DWARF in FDPIC mode. This patch replaces the older
892-disable-dwarf-bfin.patch, as instead of disabling DWARF support, it
fixes it. This was reported as gcc PR68468.

In order to get C++ working without unresolved symbols, we also need to
disable symbol versioning (--disable-symvers). This is a remaining issue
in gcc which will be investigated at a later point.

Since this commit fixes C++ support in Blackfin, it re-enables the
selection of C++ support for this architecture.

Fixes:
  (alsa-lib emutls)
  http://autobuild.buildroot.net/results/8544ce58d75820666579db93a25ca5656a8efa8e/
  (cairo emutls)
  http://autobuild.buildroot.net/results/88b02a5dd5408318941ccbfcea0a9cbaa331500a/
  (audiofile c++)
  http://autobuild.buildroot.net/results/394e530c5dcd9ccb590eb151aeaadb37d11e0e39/
  (assimp c++)
  http://autobuild.buildroot.net/results/01f4be126c2d786a5ad7f220c2cf60539888a480/
  (bellagio c++)
  http://autobuild.buildroot.net/results/ada/ada44228bf13ec05382275bd6571396f5ba2b1f7/

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-20 11:47:46 +02:00
Samuel Martin
5077bdd939 package/gcc: fix fortran support
Fortran depends on libquadmath when available, make the buildroot
toolchain option depends on this new hidden symbol,

[Vincent: only do "HOST_GCC_FINAL_USR_LIBS += libquadmath" for i386 and
x86_64, otherwise it will fail saying "libquadmath.a: file not found"]

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Thomas Petazzoni
ce34ce8ec5 gcc: remove occurrence of eglibc
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-28 22:26:15 +02:00
Thomas Petazzoni
416fd9cd13 Replace (e)glibc by glibc
Following the removal of eglibc support, this commit replaces all
occurences of "(e)glibc" by just "glibc". Most of the occurences are in
package Config.in comments.

In addition, when the form "an (e)glibc ..." was used, it is replaced by
"a glibc ...".

[Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain,
        systemd / liquid-dsp tweaks as suggested by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-28 22:19:22 +02:00
Waldemar Brodkorb
015322fccb toolchain: add coldfire support
Add support for m68k/coldfire. A gcc patch is required
to avoid gcc ICE.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 18:50:46 +02:00
Max Filippov
6a1274705d Revert "gcc/gcc-final: pass TARGET_ABI flags to configure with --enable-cxx-flags"
This reverts commit 2dcab526a9.

Now that gcc correctly propagates CXXFLAGS_FOR_TARGET for libstdc++
build this is no longer needed.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-15 23:14:35 +01:00
Peter Korsgaard
cc257ee493 Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-12-01 23:24:07 +01:00
Yann E. MORIN
bf23db235c package/gcc: comment on why we override the generic configure commands
The explanations given in the commit log of 7d6c79 (Compile static
versions of gcc libraries) do not explain why we have to provide custom
configure commands, instead of just adding --enable-static to the
configure options.

Add a comment in the code that explains why that is so. Add a pointer to
the ML archives with the explanations, too.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jérôme Pouiller <jezz@sysmic.org>
Acked-by: Jérôme Pouiller <jezz@sysmic.org>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-23 18:37:20 +01:00
Steven Noonan
70dffaa132 gcc-final: hard link TARGET-cc -> TARGET-gcc
Doing a symlink results in incorrect behavior:

    $ x86_64-buildroot-linux-gnux32-cc
    --version
    ccache: error: execv of [...]/x86_64-buildroot-linux-gnux32-cc.br_real.br_real failed: No such file or directory

    $ x86_64-buildroot-linux-gnux32-gcc --version
    x86_64-buildroot-linux-gnux32-gcc.br_real (Buildroot 2015.11-git-00965-g8d89653-dirty) 5.2.0
    Copyright (C) 2015 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Note the double .br_real on the invocation by toolchain-wrapper.

[Thomas: use 'ln -f' instead of 'cp -l', as suggested by Arnout.]

Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-08 15:00:35 +01:00
Thomas Petazzoni
4a8478b728 gcc: use <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDES
As reported by Steven Noonan, the variable recently introduced in the
package infrastructure to exclude certain parts of an archive from
being extracted is <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDES. However,
the gcc code was incorrectly using <pkg>_TAR_EXCLUDES. This commit
fixes that.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Steven Noonan <steven@uplinklabs.net>
2015-11-04 08:32:39 +01:00
Yann E. MORIN
e3b46be7f4 package/gcc: use generic extract commands
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>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-03 22:22:51 +01:00
Thomas Petazzoni
a7463a6c81 gcc: pass explicit gcc_cv_libc_provides_ssp also to gcc-final
During the gcc-initial build, we already pass
gcc_cv_libc_provides_ssp=yes explicitly when SSP support will be
available in the C library: at this point in time the C library is not
yet built, so gcc cannot detect if it will support SSP or not.

However, it turns out that there are some situations for which it is
also useful to tell gcc explicitly whether the SSP support is
available or not: the gcc logic to decide whether uClibc has SSP
support or not is broken since uClibc-ng bumped the glibc version it
pretends to be.

So, this commit makes sure that we explicitly pass
gcc_cv_libc_provides_ssp both to gcc-initial and gcc-final, and that
we're always passing either 'yes' or 'no'.

Fixes:

   http://autobuild.buildroot.org/results/778/778e6309ba834cc70f8243a4f6c664c0bcaeb7c5/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-18 15:35:49 +02:00
Arnout Vandecappelle
2f8dc29c1d gcc: remove unsafe patch check (poison system dirs) patch
Now that the calls to gcc always pass through the toolchain wrapper, it
is no longer necessary to patch gcc to support poisoning.

This does have the disadvantage that there is no unsafe path check for
libc, libgcc and libstdc++ (all of these are built before the wrapper
exists). But we can assume that the toolchain components themselves
should be pretty safe.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:20 +02:00
Arnout Vandecappelle
919c06c282 gcc: use toolchain wrapper
We have a toolchain wrapper for external toolchain, but it is also
beneficial for internal toolchains, for the following reasons:

1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the
   compiler even if a package's build system doesn't honor CFLAGS.
2. It allows us to do the unsafe path check (i.e. -I/usr/include)
   without patching gcc.
3. It makes it simpler to implement building each package with a
   separate staging directory (per-package staging).
4. It makes it simpler to implement a compiler hash check for ccache.

The wrapper is reused from the external toolchain. A third CROSS_PATH_
option is added to the wrapper: in this case, the real executable is in
the same directory, with the extension .real.

The creation of the simple symlinks is merged with the creation of the
wrapper symlinks, otherwise part of the -gcc-ar handling logic would
have to be repeated.

The complex case-condition could be refactored with the one for the
external toolchain, but then it becomes even more complex because
they each have special corner cases. For example, the internal
toolchain has to handle *.real to avoid creating an extra indirection
after host-gcc-{final,initial}-rebuild.

Instead of creating the .real files, it would also have been possible
to install the internal toolchain in $(HOST_DIR)/opt, similar to what
we do for the external toolchain. However, then we would also have to
copy things to the sysroot and do more of the magic that the external
toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much
simpler.

Note that gcc-initial has to be wrapped as well, because it is used for
building libc and we want to apply the same magic when building libc.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:20 +02:00
Arnout Vandecappelle
6d475da9a0 host-gcc-final: don't install a potentially dead symlink
gcc used to be installed into $(HOST_DIR)/usr/$(GNU_TARGET_NAME) but
since gcc 4.9 this is no longer the case.  Therefore, the cc -> gcc
symlink that is created in that we create in that directory is dead.

There don't seem to have been any problems due to the missing gcc and
cc in $(HOST_DIR)/usr/$(GNU_TARGET_NAME), things seems to build fine
without it. The cc -> gcc symlinks in general should not be needed
anyway, since we always pass the appropriate CC variable to the
package build system.

Therefore, let's remove the cc -> gcc symlink in
$(HOST_DIR)/usr/$(GNU_TARGET_NAME) - also for pre-4.9 gcc versions.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-20 14:35:27 +02:00
David Kessler
c00fd2845e gcc: add support for fortran
Signed-off-by: David Kessler <DJKessler@me.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-19 14:48:33 +02:00
Gustavo Zacarias
e1cf34a395 gcc/gcc-final: install libatomic via HOST_GCC_FINAL_GCC_LIB_DIR
Otherwise it's a no-op for sh4.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-06 03:15:23 +02:00
Max Filippov
2dcab526a9 gcc/gcc-final: pass TARGET_ABI flags to configure with --enable-cxx-flags
libstdc++ is in all regards a normal library, it needs to be built with
TARGET_ABI flags, otherwise linking it with other C++ code may fail.

Pass TARGET_ABI flags to gcc-final configure script in the
--enable-cxx-flags parameter.

Fixes:
  http://autobuild.buildroot.net/results/81a3bca5cbcf789c7ce1aa221a6a4154dd7c3917/
  http://autobuild.buildroot.net/results/4943b214c29951ecc7af0a1f360b6454485c0b9b/

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-05-31 22:51:21 +02:00
Waldemar Brodkorb
19d5953bf1 sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.

So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.

Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.

Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 (ARM and SH4 uClibc toolchain builds)
2015-05-03 16:30:36 +02:00
Yann E. MORIN
fcd6589021 package/gcc: add hashes
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-23 23:01:47 +02:00
Gustavo Zacarias
5b9f64e420 gcc-final: install libatomic
It's required in some 32-bit architectures for the extended (64-bit)
atomic operations, like __sync_add_and_fetch_8.
These arches are at least: i386, mips & mipsel.

Target size growth is ~15 KiB for ARM.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-19 14:39:59 +02:00
Gustavo Zacarias
c0d6625e5e package infra: drop non-lfs support
Now that largefile is mandatory remove support for non-lfs
tweaks/variables in the package infra and the gcc build.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:43:01 +02:00
Thomas Petazzoni
665e13c85e Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.

As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.

This also helps preparing the addition of other options to select
shared, shared+static or just static.

Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 22:48:13 +01:00
Thomas Petazzoni
3e0900c04c gcc: enable poison system directories option
This commit enables the poison system directories option, which is now
available thanks to the gcc patches that have been added.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
2014-12-11 00:05:52 +01:00
Gustavo Zacarias
65d5ec3708 package/gcc/mpfr: remove deprecated features
Remove the fortran and objective C language support since these have
been deprecated since more than a year ago.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-12-01 20:05:59 +01:00
Jerzy Grzegorek
1769933d98 package: indentation cleanup
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-26 05:47:05 +01: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
Gustavo Zacarias
169141a3eb gcc-final: disable shared build for static
Disable shared build for host-gcc-final when building for static targets.
We really want static or shared, there's no such thing as "preferring static"
since we can't choose with any degree of granularity for which packages.
And it confuses linking scripts having both available at the same time. Fixes:
http://autobuild.buildroot.net/results/c54/c54bdf88eff6d60c7001cb0e2cb6792cc75178db/

[Thomas: slightly amend the commit to factorize the installation of
static libraries.]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-30 20:25:10 +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
12d150727a Strip *.so* and not only executable files
Our current stripping strategy requires that shared libraries have the
executable permission. However, this is by far not something
recognized as a standard behavior: Debian/Ubuntu distributions for
example do not have executable permissions on their
libraries. Therefore, pushing to upstream packages fixes that add the
executable permissions is not easy.

As a result, this commit improves the stripping logic so that it not
only strips the files that are executable, but also the ones that
match '*.so*', which should match both the shared libraries and the
dlopen()'able plugins, as long as they have a .so extension.

Thanks to this addition, a number of manual "chmod +x" done by various
packages can be removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-04 18:10:15 +01:00
Peter Korsgaard
de13e31a16 Rename BUILDROOT_LIBC to BR_LIBC
No functional change, but internal variables should be name BR_foo, not
BUILDROOT_foo (I think ..).

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-04 15:06:46 +01:00
Jérôme Pouiller
7d6c79ed88 Compile static versions of gcc libraries
Since default configure options for host packages include
--disable-static, gcc was not configured to build static version of its
libraries (libgcc.a, libstdc++.a, ...).

This patch replace --disable-static by --enable-static in configure
command. Notice some options was removed sinces they was ignored by gcc
configure script.

Once it was compiled, this commit takes care to copy static libraries to
$STAGING

Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-11 17:19:17 +01:00
Thomas Petazzoni
530777aaeb gcc: provide option to enable mudflap support
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>
2013-09-15 23:24:35 +02:00
Thomas Petazzoni
df9bbb779f gcc/gcc-final: use the common HOST_GCC_CONFIGURE_SYMLINK macro
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>
2013-09-15 23:01:06 +02:00
Thomas Petazzoni
14a2d0b5ab toolchain: add support for glibc
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>
2013-09-15 22:58:37 +02:00
Thomas Petazzoni
cd04552e89 gcc: fix Objective-C support
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>
2013-09-15 22:57:29 +02:00
Thomas Petazzoni
69a534b2aa gcc: fix Fortran support
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>
2013-09-15 22:54:41 +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
Markos Chandras
027ef3f2b2 gcc-final: Drop obsolete code for handling lib64
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>
2013-08-28 16:17:19 +02:00
Francois Perrad
7fc685c9e0 gcc: fix !BR2_LARGEFILE builds
see http://lists.busybox.net/pipermail/buildroot/2013-August/076278.html

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Tested-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-08-07 17:50:21 +02:00
Peter Korsgaard
fedf4815ba gcc-final: ensure TARGET_DIR/usr/lib exists before copying to it
Got dropped in the toolchain/gcc -> package/gcc conversion.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-17 09:31:06 +02:00
Thomas Petazzoni
d2e3cc389d gcc: create symbolic link to ld-linux in EABIhf/gcc 4.7/eglibc
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>
2013-07-16 15:22:10 +02:00
Thomas Petazzoni
f03a9be4c3 gcc: remove BR2_GCC_SHARED_LIBGCC option
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>
2013-07-11 16:26:52 +02:00
Thomas Petazzoni
8d29893893 eglibc: enable support in the Buildroot toolchain backend
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>
2013-07-04 11:08:27 +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