aboutsummaryrefslogtreecommitdiff
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
...
| * arch/mips: inverse the mfpxx logicGravatar Yann E. MORIN2017-11-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * arch/arm: some variants need different gcc versionsGravatar Yann E. MORIN2017-11-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take the conditions currently specified in the gcc version choice. Also, the conditions explained in the commit log for 78c2a9f7 were not all properly applied, especially the a57-a53 combo needs gcc-6, but 78c2a9f7 forgot to add the condition to gcc-4.9. gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery external toolchain, which uses 4.8, was not excluded for those two cores. Now it is. Remove the arch condition from gcc and the external toolchains. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain/external: hide versions too old for the current archGravatar Yann E. MORIN2017-11-2411-0/+15
| | | | | | | | | | | | | | | | | | Hide the toolchains if the arch requires a gcc version more recent than the one they provide. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain/external-custom: hide versions too old for the current archGravatar Yann E. MORIN2017-11-241-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an architecture expresses a requirement on the gcc version, limit the version choice in the custom external toolchain. The rationale being that there is no point in offering that version to the user if we know before-hand that the gcc version will not work for that architecture. All versions below the minimum we support is just made conditional to that minimum as well, including the "older" entry. However, this means that the "older" entry is no longer available when the architecture requires a minimum gcc version. A user who wants to use a toolchain with a gcc older than the minimum will have no choice but to realise the toolchain is not suitable (or lie and we would catch that when checking the gcc version anyway). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain: add 4.14.x choice for headersGravatar Fabio Estevam2017-11-132-0/+9
| | | | | | | | | | Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | Fix makefile include order by using sort/wildcard.Gravatar Peter Seiderer2017-11-241-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | The 'include' directive in GNU make supports wildcards, but their expansion has no defined sort order (GLOB_NOSORT is passed to glob()). Usually this doesn't matter. However, there is at least one case where it does make a difference: toolchain/*/*.mk includes both the definitions of the external toolchain packages and pkg-toolchain-external.mk, but pkg-toolchain-external.mk must be included first. For predictability, use ordered 'include $(sort $(wildcard ...))' instead of unordered direct 'include */*.mk' everywhere. Fixes [1] reported by Petr Vorel: make: *** No rule to make target 'toolchain-external-custom', needed by '.../build/toolchain-external/.stamp_configured'. Stop. [1] http://lists.busybox.net/pipermail/buildroot/2017-November/206969.html Signed-off-by: Peter Seiderer <ps.report@gmx.net> Tested-by: Petr Vorel <petr.vorel@gmail.com> [Arnout: also sort the one remaining include, of the external docs] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain/wrapper: fake __DATE_ and __TIME__ for older gccGravatar Yann E. MORIN2017-10-221-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with version 7, gcc automatically recognises and enforces the environment variable SOURCE_DATE_EPOCH, and fakes __DATE__ and __TIME__ accordingly, to produce reproducible builds (at least in regards to date and time). However, older gcc versions do not offer this feature. So, we use our toolchain wrapper to force-feed __DATE__ and __TIME__ as macros, which will take precedence over those that gcc may compute itself. We compute them according to the specs: https://reproducible-builds.org/specs/source-date-epoch/ https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html Since we define macros otherwise internal to gcc, we have to tell it not to warn about that. The -Wno-builtin-macro-redefined flag was introduced in gcc-4.4.0. Therefore, we make BR2_REPRODUCIBLE depend on GCC >= 4.4. gcc-7 will ignore SOURCE_DATE_EPOCH when __DATE__ and __TIME__ are user-defined. Anyway, this is of no consequence: whether __DATE__ and __TIME__ or SOURCE_DATE_EPOCH takes precedence, it would yield the exact same end result since we use the same logic to compute it. Note that we didn't copy the code for it from gcc so using the same logic doesn't imply that we're inheriting GPL-3.0. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Jérôme Pouiller <jezz@sysmic.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <peter@korsgaard.com> [Arnout: rewrite commit message] Signed-off-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>
* toolchain: add glibc support for ARCv2Gravatar Evgeniy Didin2017-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Finally there's working ARC port of glibc thanks to Vineet and Cuper! This port is based on pretty recent glibc's master branch and ARC changes are being reviewed now in glibc's mailing list. Thus we again have to use sources from our GitHub but as soon as there's a glibc release with our patches applied we'll switch to upstream releases and will drop our glibc GitHub repo alltogether. Note now we cut tags in glibc repo simultaneously with tags in Binutils and GCC repos and so to make sure everything works in the best way we plan to update glibc tag together with Binutils and GCC. Also note as of today ARCompact (AKA ARCv1 ISA) is not supported in glibc but we plan to fix it soonish so for now we make glibc intentionally dependent on archs38. Also note we are not creating directory "2.26" because all patches for glibc ver 2.26 applies to arc glibc port. Signed-off-by: Evgeniy Didin <didin@synopsys.com> CC: Alexey Brodkin <abrodkin@synopsys.com> CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> CC: Waldemar Brodkorb <wbx@openadk.org> CC: Romain Naour <romain.naour@gmail.com> Cc: Cupertino Miranda <cmiranda@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/bfin: internal backend not suitable for some coresGravatar Yann E. MORIN2017-10-021-4/+0
| | | | | | | | | | | | Some cores are not supported by upstream gcc. Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: internal backend not suitable for some coresGravatar Yann E. MORIN2017-10-021-2/+0
| | | | | | | | | | | | Some cores are not supported by upstream gcc. Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/csky: internal backend not suitableGravatar Yann E. MORIN2017-10-021-1/+0
| | | | | | | | | | | | | Upstream gcc does not have support for C-Sky, and we do not have a vendor tree for it either (yet?). Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add option to disable internal toolchain backendGravatar Yann E. MORIN2017-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | Some architectures or specific cores do not have support in upstream gcc. Currently, they are individually listed as exclusions in the toolchain choice. This poses a maintainance burden, as the knowledge about what gcc version supports what architecture is split across many places: the toolchain choice, the gcc version choice, the external toolchains. As a first step, add a blind option that architectures or individual cores may select to indicate they lack support in our internal backend. Actual use of the option will come in followup patches. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/glibc: needs kernel headers >= 3.10 on powerpc64leGravatar Romain Naour2017-09-271-0/+6
| | | | | | | | | | | | | | Since glibc 2.26, kernel headers >= 3.10 are needed on powerpc64le [1]. In order to prepare the glibc bump to this version, we don't allow to build a Buildroot toolchain with kernel headers older than 3.10. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=c2ff5ec13fca1bdd1cd646a0260808386d7bd7ff Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain-external: bump version of Linaro AArch64 toolchain to 2017.08Gravatar Romain Naour2017-09-273-7/+7
| | | | | | | | | | | GDB has been updated to 8.0 version in the release. https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08 Tested with qemu_aarch64_virt_defconfig. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump version of Linaro ARMeb toolchain to 2017.08Gravatar Romain Naour2017-09-273-9/+9
| | | | | | | | | GDB has been updated to 8.0 version in the release. https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump version of Linaro ARM toolchain to 2017.08Gravatar Romain Naour2017-09-273-9/+9
| | | | | | | | | | | GDB has been updated to 8.0 version in the release. https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08 Tested with qemu_arm_vexpress_defconfig. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: detect external glibc in merged /usrGravatar Cam Hutchison2017-09-191-1/+1
| | | | | | | | | | | | | | | | | | When using an external toolchain that was built with Buildroot and a merged /usr, the dynamic linker is actually in /usr/lib. But the check_glibc macro limits the depth it is looking for the dynamic linker, and misses it when it is in /usr/lib because it is too deep. We could fix that in two ways: increase the depth in which we look for it, or follow symlinks. We choose the second solution. Signed-off-by: Cam Hutchison <camh@xdna.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain: add 4.13.x choice for headersGravatar Fabio Estevam2017-09-072-0/+9
| | | | | Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/buildroot: not available for a few mips coresGravatar Yann E. MORIN2017-08-291-0/+2
| | | | | | | | | | | | | | | | | | Commit 1b974425 (MIPS: add support for M6201 cores) explained that the new core was not supported by upstream gcc, and as of gcc-8-trunk that's still the case. Ditto for 3cfbeb83 (MIPS: add support for P6600 cores). This means that we currently allow to build an internal tolchain for those cores, yet we have no suitable gcc version. Disable the internal backend in this case. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core/pkg-toolchain-external: quiesce spurious stderrGravatar Yann E. MORIN2017-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 392b0a26f5 (toolchain-external: default BR2_TOOLCHAIN_EXTERNAL_PATH to empty), calling 'make clean' or similar can yield a spurious stderr message: dirname: missing operand Try 'dirname --help' for more information. Which is definitely baffling and unsettling... It turns out that it is pretty trivial to reproduce, and this defconfig is just enough: $ cat my-defconfig BR2_TOOLCHAIN_EXTERNAL=y $ make BR2_DEFCONFIG=$(pwd)/my-defconfig defconfig $ make clean dirname: missing operand Try 'dirname --help' for more information. [--snip--] This is because the cross-compiler is not found in the PATH (and for good reasons, I don't have it in the PATH, not even at all). So, when the cross-compiler is not found in the path, we simply continue as if all was good, and postpone the check to much later, when we try to copy the toolchain libs... So, use a make construct rather than calling to the shell: $(dir ...) does not whine if passed nothing. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/arm: add big.LITTLE cpu variantsGravatar Yann E. MORIN2017-07-222-0/+6
| | | | | | | | | | | | | | | | | | | | | | | The big.LITTLE configurations can be optimised for by gcc, and a few users wonder what they should choose when they have such CPUs. Add new entries for those big.LITTLE configurations. Note: the various combos were added in various gcc versions, but only really worked in later versions: Variant | Introduced in | First built in ----------+---------------+---------------- a15-a7 | 4.9 | 4.9 a17-a7 | 5 | 5 a57-a53 | 4.9 | 6 a72-a53 | 5 | 6 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: add option for toolchains supporting -mfpxxGravatar Vicente Olivert Riera2017-07-211-0/+4
| | | | | | | | | | | | | -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>
* arch/mips: add option for toolchains supporting -mnanGravatar Vicente Olivert Riera2017-07-212-0/+6
| | | | | | | | | | -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>
* arch/mips: add support for MIPS32 FP modeGravatar Vicente Olivert Riera2017-07-162-0/+19
| | | | | | | | | | | | | | | | | | | | MIPS32 support different FP modes (32,xx,64), so give the user the opportunity to choose between them. That will cause host-gcc to be built using the --with-fp-32=[32|xx|64] configure option. Also the -mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the toolchain wrapper. FP mode option shouldn't be used for soft-float, so we add logic in the toolchain wrapper if -msoft-float is among the arguments in order to not append the -fp[[32|xx|64] option, otherwise the compilation may fail. Information about FP modes here: - https://sourceware.org/binutils/docs/as/MIPS-Options.html - https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: add support for MIPS NaNGravatar Vicente Olivert Riera2017-07-162-0/+8
| | | | | | | | | | | | | | | | | MIPS supports two different NaN encodings, legacy and 2008. Information about MIPS NaN encodings can be found here: https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html NaN legacy is the only option available for R2 cores and older. NaN 2008 is the only option available for R6 cores. R5 cores can have either NaN legacy or NaN 2008, depending on the implementation. So, if the user selects a generic R5 target architecture variant, we show a choice menu with both options available. For well known R5 cores we directly select the NaN enconding they use. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: default BR2_TOOLCHAIN_EXTERNAL_PATH to emptyGravatar Arnout Vandecappelle2017-07-101-2/+6
| | | | | | | | | | | | It makes no sense to default to an arbitrary path. In addition, it in fact works correctly when it is empty. In that case, the toolchain will be searched in PATH. Update the help text to explain the above, and also that the compiler is supposed to be in the bin subdirectory. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-wrapper: remove remaining references to HOST_DIR/usrGravatar Arnout Vandecappelle2017-07-101-2/+2
| | | | | | | | | | | Commit 14151d77af20ec50eeba6e30465debf87b35faaa that eliminated $(HOST_DIR)/usr seriously missed the toolchain-wrapper - only a single reference was updated, the other three were missed. Commit 015d68c84c9c6ad6f6d41f181d19d813f309088b removed one more. This commit finally removes the two remaining ones. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: add 4.12.x choice for headersGravatar Joel Stanley2017-07-082-0/+9
| | | | | Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-wrapper: fix breakage after host/usr removalGravatar Arnout Vandecappelle2017-07-071-1/+1
| | | | | | | | | | | | | | | | The toolchain wrapper, when called through PATH, strips the last three levels of /proc/self/exe to find HOST_DIR. However, after the host/usr removal, this should be just two levels. The toolchain wrapper has different logic for when it is called with a full path (i.e. $HOST_DIR/usr/bin/arm-linux-gcc) then when it is called through the PATH (i.e. just arm-linux-gcc). The latter is never used internally in Buildroot, that's why this wasn't discovered through testing. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Mark Jackson <mpfj-list@newflow.co.uk> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: drop reference to non-existing variableGravatar Baruch Siach2017-07-061-4/+0
| | | | | | | | | | Commit 32bec8ee2fb0 (toolchain-external: copy ld*.so* for all C libraries) removed the definition of TOOLCHAIN_EXTERNAL_MUSL_LD_LINK. Remove also the reference to it. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: replace absolute symlinks by relative symlinks during sysroot copyGravatar Thomas Petazzoni2017-07-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") we changed how the musl dynamic linker symbolic link was being created. Instead of having specific logic in Buildroot, we switched to simply copying the ld*.so.* symbolic link from staging to target, as well as the target of this symbolic link. However, it turns out that by default, musl creates its dynamic linker symbolic link with an absolute path as the target of the link: /lib/libc.so. Therefore, external Musl toolchains built with Buildroot look like this: lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so The principle of the copy_toolchain_lib_root function, which is used to copy libraries from staging to target, is to copy symbolic links and follow their targets. In this case, it means we end up copying /lib/libc.so (from the host machine) into the target folder. From there on, there are two cases: 1. /lib/libc.so exists in your host system. It gets copied to the target. But later on, Buildroot also copies /lib/libc.so from staging to target, overwriting the bogus libc.so. So everything works fine, even though it's admittedly ugly. 2. /lib/libc.so doesn't exist in your host system. In this case, the build fails with no clear error message. This problem does not happen with Musl toolchains built by Crosstool-NG, because Crosstool-NG replaces the absolute target of the dynamic linker symbolic link by a relative path. However, since we want to support existing Buildroot Musl toolchains and generally work with the fact that Musl by default installs an absolute symlink, the following commit improves the copy_toolchain_sysroot function to replace symbolic links with an absolute destination to use a relative destination. I.e, in staging, the ld-musl-armhf.so.1 symbolic link looks like this: lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so Fixes: http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers.mk: fix creation of DESTDIR in copy_toolchain_lib_rootGravatar Arnout Vandecappelle2017-07-051-2/+1
| | | | | | | | | | | | | | | | | | In commit b3cc7e65ee, the definition of the DESTDIR variable was moved down into the loop that follows symlinks in the libraries that are copied to target. However, the corresponding mkdir was not moved down, so that no directories are ever created. In practice, this mkdir is normally redundant since the directories should already have been created as part of creating STAGING_DIR. Still, the current situation is clearly wrong, so fix it by moving the mkdir down to after the assignment to DESTDIR. While we're at it, also remove a redundant empty line. It's a leftover from when a lot of variables were declared above. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Globally replace $(HOST_DIR)/usr/bin with $(HOST_DIR)/binGravatar Arnout Vandecappelle2017-07-052-5/+5
| | | | | | | | | | | Since things are no longer installed in $(HOST_DIR)/usr, the callers should also not refer to it. This is a mechanical change with git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g' Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers.mk: simplify ld.so fixup in copy_toolchain_sysrootGravatar Thomas Petazzoni2017-07-051-4/+1
| | | | | | | | | | | | | | | | | In copy_toolchain_sysroot, if no ld.so has been found in the STAGING_DIR after the sysroot copy, we look at ARCH_SYSROOT_DIR if a ld.so is available there. We do this for both ld*.so and ld*.so.*. However, when copying thing from staging to target (as listed in TOOLCHAIN_EXTERNAL_LIBS), we only match on ld*.so.*. This would mean that even if a dynamic linker matching ld*.so but not ld*.so.* was copied into staging by copy_toolchain_sysroot, it would anyway not be copied to the target filesystem, making the system unusable. Therefore, we can remove the special case on ld*.so, and keep only ld*.so.*. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: also put libgcc_s.so unconditionally in ↵Gravatar Thomas Petazzoni2017-07-051-3/+3
| | | | | | | | | | TOOLCHAIN_EXTERNAL_LIBS libgcc_s.so is now added to TOOLCHAIN_EXTERNAL_LIBS for glibc/uclibc in one place, and for musl in another place. Bottom line: it should be in TOOLCHAIN_EXTERNAL_LIBS unconditionally. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: copy ld*.so* for all C librariesGravatar Thomas Petazzoni2017-07-051-29/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, for the dynamic loader, we're copying ld*.so* for glibc and uClibc, except for glibc/EABIhf where we are explicitly copying ld-linux-armhf.so.*. For musl, we're not copying the dynamic linker because it's simply a symbolic link to libc.so. However, the name of the musl dynamic linker changes from one architecture to the other, and we don't handle all cases. Since handling the musl dynamic linker symlink creation is becoming more and more annoying to maintain, this commit makes musl use the same mechanism as glibc/uClibc: put the dynamic linker in TOOLCHAIN_EXTERNAL_LIBS. In addition, the special condition on glibc/EABIhf was added in 11ec38b6950cf3337b52fb97f27c2fd7c776c5c2 ("toolchain-external: fix Linaro ARM toolchain support") because an old Linaro toolchain had two dynamic loaders, and we wanted to copy only one. But 1/ this is old and 2/ having the two dynamic linkers doesn't really matter. So this commit simply unconditionally adds "ld*.so*" to TOOLCHAIN_EXTERNAL_LIBS, regardless of the C library being chosen. It re-uses the musl dynamic linker symlink from the sysroot, which makes it always correct, and allows us to remove the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook, and all the related logic. This commit therefore solves two problems with the musl dynamic linker symbolic link creation logic: 1 We support all architectures, without having to hardcode in Buildroot the mapping between the CPU architecture and the corresponding dynamic linker name. For example, our current logic was not handling the mips64+n32 ABI case, where the dynamic linker is named ld-musl-mipsn32el.so.1. 2 We support Crosstool-NG musl toolchains, where the dynamic linker is in /lib, but libc.so is in /usr/lib. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- This commit therefore replaces: - https://patchwork.ozlabs.org/patch/780411/ (was another solution for solving problem 1 above) - https://patchwork.ozlabs.org/patch/763977/ and https://patchwork.ozlabs.org/patch/748974/ (was another solution for solving problem 2 above)
* toolchain/helpers.mk: re-evaluate DESTDIR in copy_toolchain_lib_rootGravatar Thomas Petazzoni2017-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | copy_toolchain_lib_root copies libraries from staging to target, resolving and copying symbolic links along the way. The most inner loop, a "while" loop, starts from an initial name, and if it's a symbolic link, gets resolved to the target, and the loop iterates until we reach a real file. However, the destination folder where the symbolic link or real file is created is computed in DESTDIR only once, before this loop starts. Therefore, this loop works fine when all symbolic links in the chain, and the real file all belong to the same directory. But it doesn't do the correct thing when the symbolic link and/or real file are in different folder. An example is Crosstool-NG musl toolchains, where the dynamic loader is in /lib/ld-musl*.so but points to ../usr/lib/libc.so. With the current logic, we copy /lib/ld-musl*.so to /lib, but we also copy libc.so to /lib instead of the expected /usr/lib. This currently doesn't cause any problem because the musl dynamic linker is manually created by the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook. However, this logic has a number of problems, so in a followup commit, we are going to put the musl dynamic linker in TOOLCHAIN_EXTERNAL_LIBS, which will cause it to be copied by copy_toolchain_lib_root. But we obviously want the link and its target to be copied to the right place, hence this fix. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* pkg-cmake: move configuration files out of $(HOST_DIR)/usrGravatar Arnout Vandecappelle2017-07-051-2/+2
| | | | | | | | | | | Move toolchainfile.cmake and Buildroot.cmake from $(HOST_DIR)/usr/share/buildroot to $(HOST_DIR)/share/buildroot. Build-tested with a bunch of cmake packages. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Eliminate $(HOST_DIR)/usrGravatar Arnout Vandecappelle2017-07-052-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use $(HOST_DIR)/usr as the prefix for host packages. That has a few disadvantages: - There are some things installed in $(HOST_DIR)/etc and $(HOST_DIR)/sbin, which is inconsistent. - To pack a buildroot-built toolchain into a tarball for use as an external toolchain, you have to pack output/host/usr instead of the more obvious output/host. - Because of the above, the internal toolchain wrapper breaks which forces us to work around it (call the actual toolchain executable directly). This is OK for us, but when used in another build system, that's a problem. - Paths are four characters longer. To allow us to gradually eliminate $(HOST_DIR)/usr while building packages, replace it with a symlink to . The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and $(HOST_DIR)/usr/lib that were added previously are removed again. Note that the symlink creation will break when $(HOST_DIR)/usr already exists as a directory, i.e. when rebuilding in an existing output directory. This is necessary: if we don't break it now, the following commits (which remove the usr part from various variables) _will_ break it. At the same time as creating this symlink, we have to update the external toolchain wrapper and the external toolchain symlinks to go one directory less up. Indeed, $(HOST_DIR) is one level less up than it was before. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: drop BR2_NEEDS_GETTEXT{,_IF_LOCALE}Gravatar Thomas Petazzoni2017-07-051-14/+0
| | | | | | | | | 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>
* toolchain: introduce BR2_TOOLCHAIN_HAS_FULL_GETTEXTGravatar Thomas Petazzoni2017-07-042-0/+7
| | | | | | | | | | | | | 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>
* toolchain: CodeSourcery AMD64 affected by PR19615Gravatar Romain Naour2017-07-042-0/+6
| | | | | Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: skip ld-musl symlink on static buildGravatar Baruch Siach2017-07-021-1/+1
| | | | | | | | | | Static build with external musl toolchain leaves a dangling symlink to libc.so. Don't create that symlink on static build. Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* glibc: remove version choiceGravatar Waldemar Brodkorb2017-06-241-2/+3
| | | | | | | | | | | | | We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library. No legacy handling required as only version choice is removed. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: move 3.2 kernel headers dependency to the libc choice in toolchain/toolchain-buildroot/Config.in file, and added a Config.in comment about it.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: update list of toolchainsGravatar Baruch Siach2017-06-201-2/+1
| | | | | | | | Remove mention of toolchains the we don't have. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: remove CodeSourcery sh toolchainGravatar Baruch Siach2017-06-205-56/+0
| | | | | | | | | | | | | | | | | | | | Since glibc 2.17, executable link command need not include the -lrt option for clock_* system calls. As a result, over time less and less software packages bother to check whether to toolchain needs -lrt. We are now at a point where maintainers refuse to add this complexity into their build system. This requires Buildroot to carry patches fixing this issue indefinitely. glibc 2.17 is now 4.5 years old. There is no reason to use an older version with current software. This commit removes the predefined profile for CodeSourcery sh toolchain that is based on glibc 2.16. One may still use the custom external toolchain support in Buildroot to get this toolchain back, and deal with any build issues that this toolchain causes. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: remove CodeSourcery x86 toolchainGravatar Baruch Siach2017-06-205-57/+2
| | | | | | | | | | | | | | | | | | | | Since glibc 2.17, executable link command need not include the -lrt option for clock_* system calls. As a result, over time less and less software packages bother to check whether to toolchain needs -lrt. We are now at a point where maintainers refuse to add this complexity into their build system. This requires Buildroot to carry patches fixing this issue indefinitely. glibc 2.17 is now 4.5 years old. There is no reason to use an older version with current software. This commit removes the predefined profile for CodeSourcery x86 toolchain that is based on glibc 2.16. One may still use the custom external toolchain support in Buildroot to get this toolchain back, and deal with any build issues that this toolchain causes. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/toolchain-common.in: adjust BR2_TOOLCHAIN_HAS_GCC_BUG_64735 for GCC 7Gravatar Jörg Krause2017-06-061-0/+1
| | | | | | | | 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>
* Merge branch 'next'Gravatar Peter Korsgaard2017-06-012-0/+9
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * package/gcc: add support for gcc 7Gravatar Romain Naour2017-05-242-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: https://github.com/gcc-mirror/gcc/commit/1701058da920d27de87dc82e8d327b8ca930e997 892-libgcc-mkmap-symver-support-skip_underscore.patch: https://github.com/gcc-mirror/gcc/commit/6c8f362e1f17cce05131eb8ff53963d64bc69484 893-libgcc-config-bfin-use-the-generic-linker-version-in.patch: https://github.com/gcc-mirror/gcc/commit/966d046c08ba50fc988ac614f84f2d49c1546e28 894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch: https://github.com/gcc-mirror/gcc/commit/397d0e43abb943f1fe57801220e7e46bc6636c7c 895-bfin-define-REENTRANT.patch: https://github.com/gcc-mirror/gcc/commit/da89a4dcdf75bc3134f73520535c949bbbb0c845 940-uclinux-enable-threads.patch: https://github.com/gcc-mirror/gcc/commit/b9ce54109ec78d18f6123a1e54aae1293bede716 941-mips-Add-support-for-mips-r6-musl.patch: https://github.com/gcc-mirror/gcc/commit/83717065090bb8b954556d1216dd9dc397dc0243 Remove obsolete patches: 301-missing-execinfo_h.patch: boehm-gc removed from gcc sources: https://github.com/gcc-mirror/gcc/commit/baf71228766058f5541d929891237d394376c975 830-arm_unbreak_armv4t.patch: SUBTARGET_CPU_DEFAULT removed: https://github.com/gcc-mirror/gcc/commit/ff3caa3ade14a42d5ab7e81cbd3605fe15aa998d 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>