NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
f201ca9d0d
kumquat-buildroot/package/musl/Config.in

13 lines
411 B
Plaintext
Raw Normal View History

toolchain: include C libraries in legal-info So far, the legal-info infrastructure was not exporting the legal info for the C libraries. This is because the legal-info only acts on packages defined in $(TARGETS). But the C libraries are never added to $(TARGETS), since there is no corresponding BR2_PACKAGE_<C-LIBRARY>. This patch adds such symbols for the 4 C libraries we support in our internal backend: uClibc, glibc, eglibc and musl. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-25 22:06:27 +02:00
config BR2_PACKAGE_MUSL
bool
default y
package/m*/Config.in: fix ordering of statements The check-package script when ran gives warnings on ordering issues on all of these Config files. This patch cleans up all warnings related to the ordering in the Config files for packages starting with the letter m in the package directory. The appropriate ordering is: type, default, depends on, select, help See http://nightly.buildroot.org/#_config_files for more information. Signed-off-by: Adam Duskett <Adamduskett@outlook.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-22 19:17:59 +02:00
depends on BR2_TOOLCHAIN_USES_MUSL
package/c-libraries: need linux-headers Now that we check that a target package in the _DEPENDENCIES of another package has to be enabled in config, all target packages must have a kconfig symbol. Add a Kconfig symbol for linux-headers, and select it from the packages that depends on it (C libraries). Also remove the now-misleading comments "for legal-info" from the C libraries. Fixes: http://autobuild.buildroot.org/results/2a9/2a9e5d27b34357819b44f573a834da1ba5079030/ ... and numerous similar failures ... 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>
2015-12-30 00:10:38 +01:00
select BR2_PACKAGE_LINUX_HEADERS
musl: no SSP on i386 and PowerPC Due to what appears a bug in gcc according to the musl developers, but that the gcc developers don't want to fix, SSP support currently don't work on i386 and PowerPC with musl. Additional details can be found at: http://www.openwall.com/lists/musl/2016/12/04/2 OpenWRT and Alpine Linux both have musl and gcc patches to work around the issue, but in the context of Buildroot, we at this point don't care enough about SSP support specifically with musl on those architectures to carry additional patches. Currently, having SSP enabled with musl/i386 causes a number of build failures in the autobuilders: cups, ipmiutil, openssh, ruby, stunnel, sudo and mosh at least all fail to build because of this. So we simply disable SSP support in the toolchain when musl is used on i386 and PowerPC. The PowerPC case is not tested in the autobuilders, but has been reproduced locally and is also fixed by this patch. Fixes: mosh http://autobuild.buildroot.net/results/60aa12f1aed08e3b7a98f9ce7091bee3a44d692c/ ipmi-util http://autobuild.buildroot.net/results/fb9a071b8739527f424cfe2886ec480f438f70ab/ cups http://autobuild.buildroot.net/results/486dea944d6ecba5c4e6e8ac664261c1909f4b4c/ openssh http://autobuild.buildroot.net/results/742a8bf4726de6e9ba6926e3fb6019a434454e48/ sudo http://autobuild.buildroot.net/results/682531f368c4e982cafe9e625dd41f6d8c7f93f9/ ruby http://autobuild.buildroot.net/results/dac660f96c7f85e933a6b82cf61edd429eeae9aa/ stunnel http://autobuild.buildroot.net/results/cee52505f1ac2da2f5ba86c9ebfd1f5cd9e301be/ Thanks to Yann E. Morin for suggesting to simply disable SSP support rather than trying to fix it. [Peter: add comment explaining why] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-15 11:50:52 +01:00
# SSP broken on i386/ppc: http://www.openwall.com/lists/musl/2016/12/04/2
toolchain: disable SSP support if CFI support in binutils is missing As reported by [1], SSP support is missing in the Buildroot toolchain for microblaze even if it's requested by selecting BR2_TOOLCHAIN_HAS_SSP config option. In Buildroot, we are using libssp provided by the C library (glibc, musl, uClibc-ng) when available. We are not using libssp from gcc. So for a microblaze glibc based toolchain, the SSP support is enabled unconditionally by a select BR2_TOOLCHAIN_HAS_SSP. BR2_microblazeel=y BR2_TOOLCHAIN_BUILDROOT_GLIBC=y BR2_KERNEL_HEADERS_4_14=y BR2_BINUTILS_VERSION_2_30_X=y BR2_GCC_VERSION_8_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y While building the toolchain, we are building host-binutils which provide "as" (assembler) and host-gcc-initial wich provide a minimal cross gcc (C only cross-compiler without any C library). When SSP support is requested, gcc_cv_libc_provides_ssp=yes is added to the make command line (see [2] for full details) With this setting, the SSP support is requested but it's not available in the end and the toochain build succeed. When the microblaze toolchain is imported to Biuldroot (2018.05) as external toolchain with BR2_TOOLCHAIN_EXTERNAL_HAS_SSP set, the build stop with : "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" The test is doing the following command line: echo 'void main(){}' | [...]/host/bin/microblazeel-linux-gcc.br_real -Werror -fstack-protector -x c - -o [...]/build/.br-toolchain-test.tmp cc1: error: -fstack-protector not supported for this target [-Werror] When we look at the gcc-final log file (config.log) we can see this error several time when using the minimal gcc (from host-gcc-initial). So Why the minimal gcc doesn't support SSP? When we look at the gcc-initial log file (config.log) we can see an error with 'as': configure:23194: checking assembler for cfi directives configure:23209: [...]microblazeel-buildroot-linux-gnu/bin/as -o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:2: Error: CFI is not supported for this target conftest.s:3: Error: CFI is not supported for this target conftest.s:4: Error: CFI is not supported for this target conftest.s:5: Error: CFI is not supported for this target conftest.s:6: Error: CFI is not supported for this target conftest.s:7: Error: CFI is not supported for this target configure:23212: $? = 1 configure: failed program was .text .cfi_startproc .cfi_offset 0, 0 .cfi_same_value 1 .cfi_def_cfa 1, 2 .cfi_escape 1, 2, 3, 4, 5 .cfi_endproc This is the only relevant difference compared to a nios2 toolchain where libssp is enabled and available (nios2 is an example). "CFI" stand for "Control Flow Integrity" and it seems that SSP support requires CFI target support (see [3] for some explanation). The SSP support seems to depends on CFI support, but the toolchain infrastructure is not detailed enough to handle the CFI dependency. The NiosII toolchains built with binutils < 2.30 are also affected by this issue. This patch improve the toolchain infrastructure by adding a new BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI blind option Disable SSP support for microblaze entirely. Disable SSP support for nios2 only with Binutils < 2.30. Fixes: https://gitlab.com/free-electrons/toolchains-builder/-/jobs/72006389 [1] https://gitlab.com/free-electrons/toolchains-builder/issues/1 [2] https://git.buildroot.net/buildroot/tree/package/gcc/gcc.mk?h=2018.05#n275 [3] https://grsecurity.net/rap_faq.php Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Thomas: adjust how the BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI option is expressed.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-08 16:41:39 +02:00
select BR2_TOOLCHAIN_HAS_SSP if BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI \
&& !(BR2_i386 || BR2_powerpc)
package/musl-compat-headers: provide compatibility headers not in musl musl provides neither sys/queue.h nor sys/cdefs.h. Those two headers are however quite widely used in a lot of packages (though they should at least not use cdefs.h which is only full of mostly-legacy macros, and which is mostly an internal header of glibc and was never really meant to be exposed to, and used by packages). But we don't live in an ideal world, so a lot of packages break when those two headers are missing. We already took care of sys/queue.h with the netbsd-queue package. But the need for cdefs.h is getting more and more pressing. We rename the netbsd-queue package into musl-compat-headers, and we make it install sys/queue.h (from NetBSD) and sys/cdefs.h (a minimalist one we bundle in Buildroot). We can't use the cdefs.h from NetBSD because it includes machine-dependent headers; instead we bundle a very minimalistic one, that covers only what we need. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-18 23:50:13 +02:00
# Compatibility headers: cdefs.h, queue.h
select BR2_PACKAGE_MUSL_COMPAT_HEADERS
package/musl: add an upstream URL to Config.in Add an upstream URL to the help text in Config.in. This addresses the 'Missing' URL status in the package stats web page output. [Peter: also add URL to BR2_TOOLCHAIN_BUILDROOT_MUSL help] Signed-off-by: Mark Corbin <mark@dibsco.co.uk> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-28 18:58:42 +01:00
help
https://www.musl-libc.org/
Reference in New Issue Copy Permalink