summaryrefslogtreecommitdiffstats
path: root/package/gcc/gcc-initial/gcc-initial.mk
Commit message (Collapse)AuthorAgeFilesLines
* package/gcc: remove unused HOST_GCC_FAKE_TESTSUITERomain Naour2018-12-101-1/+0
| | | | | | | | | HOST_GCC_FAKE_TESTSUITE was removed since commit [1]. [1] 545ca6a0f2f4e0d8b3812949476ac2856264b83c Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* package/gcc: remove BR2_GCC_SUPPORTS_FINEGRAINEDMTUNEThomas Petazzoni2018-10-211-7/+2
| | | | | | | | | | | | | Since commit 8f8e9162fae5fdc1788dcf33f02b20ddaa5e6846 ("package/gcc: do not mourn avr32 for too long..."), in which we dropped AVR32 support, the BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE is always 'y'. Therefore, it is totally useless to keep this option around, and this commit removes it, making the corresponding code unconditional along the way. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* package: share downloaded files for big packagesYann E. MORIN2018-04-021-0/+5
| | | | | | | | | | | | Theses packages are given as an example of the use of the *_DL_SUBDIR feature. There maybe other packages that would benefit from that feature, they would need to be added on a case by case basis. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/xtensa: accept the overlay to be an URLYann E. MORIN2017-07-091-0/+1
| | | | | | | | | | | | | It can be interesting to get the overlay from a remote server, rather than expect it to be present locally. Since that file can be any URL, we can't know its hash, so we just exclude it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> [Thomas: use DL_DIR instead of BR2_DL_DIR.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/xtensa: allow specifying path to tarball fileYann E. MORIN2017-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | currently, specifying a custom Xtrensa core is done with two variables: - the core name - the directory containing the overlay tarball However, the core name only serves to construct the tarball name, and is not used whatsoever to configure any of the toolchain components (binutils, gcc or gdb), except through the files that are overlayed in their respective source trees. This has two main drawbacks: - the overlay file must be named after the core, - the tarball can not be compressed. Furthermore, it also makes it extremely complex to implement a download of that tarball. So, those two variables can be squeezed into a single variable, that is the complete path of the overlay tarball. Update the qemu-xtensa defconfig accordingly. Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it was previously a blind option in the last release, and there's been no release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user could have seen in any of our releases so far. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/gcc: use the Xtensa variablesYann E. MORIN2017-03-261-1/+1
| | | | | | | | | ... 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>
* gcc: the special workaround for ARC is no longer requiredWaldemar Brodkorb2016-11-231-13/+0
| | | | | | | | | It seems with the change to gcc 6.x based toolchain this workaround is no longer required. Tested with an arc hs toolchain. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/wrapper: fix 'reinstall'Jérôme Pouiller2016-10-241-1/+2
| | | | | | | | | | 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>
* gcc: rename option for ARC gccThomas Petazzoni2016-09-201-1/+1
| | | | | | | | | | | The ARC gcc version is now based on gcc 6.x and no longer gcc 4.8.x, which makes the option BR2_GCC_VERSION_4_8_ARC a bit irrelevant, as is the prompt of this option. This commit therefore renames this option to BR2_GCC_VERSION_ARC, and adjust its prompt as well. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: use <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDESThomas Petazzoni2015-11-041-1/+1
| | | | | | | | | | | 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>
* package/gcc: use generic extract commandsYann E. MORIN2015-11-031-1/+2
| | | | | | | | | | 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>
* gcc: pass explicit gcc_cv_libc_provides_ssp also to gcc-finalThomas Petazzoni2015-10-181-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gcc: use toolchain wrapperArnout Vandecappelle2015-10-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* package/gcc: fix ARC failure to build in 2 phases.Tal Zilcer2015-07-021-0/+1
| | | | | | | | | | | When working with GCC initial at override source dir mode the HOST_GCC_INITIAL_POST_PATCH_HOOKS is not called and compilation failes. The solution is to use HOST_GCC_INITIAL_POST_RSYNC_HOOKS since this hook is being called at override source dir mode. Signed-off-by: Tal Zilcer <talz@ezchip.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc/gcc-initial: fix build of the AVR32 toolchainThomas Petazzoni2014-10-091-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* .mk files: bulk aligment and whitespace cleanup of assignmentsThomas De Schampheleire2014-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* packages: rename FOO_CONF_OPT into FOO_CONF_OPTSThomas De Schampheleire2014-10-041-2/+2
| | | | | | | | | | | | 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>
* packages: rename FOO_INSTALL_OPT into FOO_INSTALL_OPTSThomas De Schampheleire2014-10-041-1/+1
| | | | | | | | | | | | 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>
* packages: rename FOO_MAKE_OPT into FOO_MAKE_OPTSThomas De Schampheleire2014-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: switch to a two stage gcc buildThomas Petazzoni2014-09-141-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gcc: fix xtensa overlay applicationMax Filippov2014-02-271-1/+1
| | | | | | | | | | | | | | | 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>
* Revert "toolchain-internal: skip gcc-intermediate when possible"Thomas Petazzoni2013-10-041-8/+0
| | | | | | | | | | | | | 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 2babed4a50fcd050abc4686e05e24d0e374d10a8. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-internal: skip gcc-intermediate when possibleThomas Petazzoni2013-09-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gcc: pass MAKEINFO=missing in the environment rather than as a ./configure argPeter Korsgaard2013-09-041-0/+3
| | | | | | | | | | | | | | 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 62322acb2ce (toolchain/gcc: disable makeinfo). Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* gcc: use BR2_EXTRA_GCC_CONFIG_OPTIONS in gcc-initial and gcc-intermediateThomas Petazzoni2013-07-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gcc-initial, gcc-intermediate, gcc-final: optimize extractionThomas Petazzoni2013-07-031-0/+2
| | | | | | | | | | | | | | | | 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>
* gcc-initial: new packageThomas Petazzoni2013-07-031-0/+37
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
OpenPOWER on IntegriCloud