Re: [Buildroot] [PATCH v3 3/4] lmbench: emulate --prefix to avoid scattering binaries all over
On Mon, 10 May 2021 11:00:48 -0700 Vineet Gupta via buildroot wrote: > - moves all lmbench binaries to /lmbench/bin/ > - scripts copied to /lmbench/scripts > - scripts/os overwritten to setup "OS" as expected by LMBench runtime scripts > > Signed-off-by: Vineet Gupta Where are lmbench binaries currently installed? Because /lmbench/ looks really really odd as an installation location. Thomas -- Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH v2] package/glibc: ARC: use upstream 2.32
On Wed, 16 Sep 2020 00:30:33 -0700 Vineet Gupta wrote: > ARC glibc port was merged upstream in 2.32 > There's no need to refer to github as it has the exact same version and > can be retired in future. > > Signed-off-by: Vineet Gupta > --- > Changes since v1: > - dropped artifacts related to github version > --- > .../glibc.hash| 2 ++ > package/glibc/arc-2020.03-release/glibc.hash | 7 --- > package/glibc/glibc.mk| 20 ++- > 3 files changed, 13 insertions(+), 16 deletions(-) > create mode 100644 > package/glibc/2.32-2-g386543bc4495f658dcce6cd4d11e4ba6574a46f5/glibc.hash > delete mode 100644 package/glibc/arc-2020.03-release/glibc.hash I've added the hashes of the license files in the glibc.hash you've added, and applied. Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH] package/glibc: ARC: use upstream 2.32
On Wed, 16 Sep 2020 04:22:36 + Vineet Gupta wrote: > On 9/15/20 6:33 AM, Thomas Petazzoni wrote: > > Hello, > > > > On Mon, 14 Sep 2020 14:37:48 -0700 > > Vineet Gupta wrote: > > > >> ARC glibc port was merged upstream in 2.32 > >> There's no need to refer to github as it has the exact same version and > >> can be retired in future. > >> > >> Signed-off-by: Vineet Gupta > >> --- > >> .../glibc.hash| 2 ++ > >> package/glibc/glibc.mk| 20 ++- > >> 2 files changed, 13 insertions(+), 9 deletions(-) > >> create mode 100644 > >> package/glibc/2.32-2-g386543bc4495f658dcce6cd4d11e4ba6574a46f5/glibc.hash > > The hash file for the ARC-specific glibc version used on Github should > > be dropped. > > The hash in the patch is from the sourceware downloaded gz. > > $ sha256sum > ../dl/glibc/glibc-2.32-2-g386543bc4495f658dcce6cd4d11e4ba6574a46f5.tar.gz > > 07f3804abbc6a23315f09568686c0e5bb81d714251cf537d25a36f826cae540b > ../dl/glibc/glibc-2.32-2-g386543bc4495f658dcce6cd4d11e4ba6574a46f5.tar.gz > I think you missed my point: with this patch, you are removing support for using the arc-2020.03-release version of glibc. Therefore the folder package/glibc/arc-2020.03-release/, which contains the hash file of glibc of the arc-2020.03-release version should be removed. Or is it me who is missing something ? Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH] package/glibc: ARC: use upstream 2.32
Hello, On Mon, 14 Sep 2020 14:37:48 -0700 Vineet Gupta wrote: > ARC glibc port was merged upstream in 2.32 > There's no need to refer to github as it has the exact same version and > can be retired in future. > > Signed-off-by: Vineet Gupta > --- > .../glibc.hash| 2 ++ > package/glibc/glibc.mk| 20 ++- > 2 files changed, 13 insertions(+), 9 deletions(-) > create mode 100644 > package/glibc/2.32-2-g386543bc4495f658dcce6cd4d11e4ba6574a46f5/glibc.hash The hash file for the ARC-specific glibc version used on Github should be dropped. Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] binutils/ARC: cleanup
Hello Vineet, On Thu, 10 Sep 2020 23:21:43 + Vineet Gupta wrote: > >> -ifeq ($(BINUTILS_VERSION),arc-2019.09-rc1) > >> +ifeq ($(BR2_BINUTILS_VERSION_ARC),y) > > Looks like we need this specific thunk anyways. When I select pristine > upstream > binutils (not ARC fork @ github), the above forces it to download from github > which it should not and will not if the tag/branch has not been mirrored > there. So I guess you're talking about the situation where a host-binutils is not enabled, and only a target binutils is used. In this case, indeed: ifeq ($(BINUTILS_VERSION),) ifeq ($(BR2_arc),y) BINUTILS_VERSION = arc-2020.03-release else BINUTILS_VERSION = 2.33.1 endif endif # BINUTILS_VERSION will kick in and set BINUTILS_VERSION to arc-2020.03-release, which will lead to: ifeq ($(BINUTILS_VERSION),arc-2020.03-release) BINUTILS_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,binutils-gdb,$(BINUTILS_VERSION)) BINUTILS_SOURCE = binutils-gdb-$(BINUTILS_VERSION).tar.gz BINUTILS_FROM_GIT = y endif being taken into account. What happens with target binutils is: (1) If a host-binutils is built (because Buildroot is building the toolchain), then we're using the same version as the host-binutils, which is defined by the choice in package/binutils/Config.in.host. (2) If not host-binutils is built (because we're using an external toolchain), then there is no version selection: we unconditionally use 2.33.1, except on ARC where we use the special ARC fork. So I guess the decision to take is: do we want to switch to using the upstream binutils, even for ARC, when no host-binutils is built ? Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH v2] binutils/ARC: cleanup
Hello Vineet, On Tue, 17 Dec 2019 13:32:53 -0800 Vineet Gupta wrote: > Remove special handling for ARC - as it is not needed for cksy etc. > > A nice side benefit is that the ARC specific version now only needs to > be specified in single place (vs 3 currently) in binutils/Config.in.host > > Signed-off-by: Vineet Gupta > --- > package/binutils/binutils.mk | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk > index a19d6940f7c1..3ae5561d67d3 100644 > --- a/package/binutils/binutils.mk > +++ b/package/binutils/binutils.mk > @@ -8,14 +8,10 @@ > # If not, we do like other packages > BINUTILS_VERSION = $(call qstrip,$(BR2_BINUTILS_VERSION)) > ifeq ($(BINUTILS_VERSION),) > -ifeq ($(BR2_arc),y) > -BINUTILS_VERSION = arc-2019.09-rc1 > -else > BINUTILS_VERSION = 2.32 > endif > -endif # BINUTILS_VERSION > > -ifeq ($(BINUTILS_VERSION),arc-2019.09-rc1) > +ifeq ($(BR2_BINUTILS_VERSION_ARC),y) > BINUTILS_SITE = $(call > github,foss-for-synopsys-dwc-arc-processors,binutils-gdb,$(BINUTILS_VERSION)) > BINUTILS_SOURCE = binutils-gdb-$(BINUTILS_VERSION).tar.gz > BINUTILS_FROM_GIT = y In fact, I was wrong, this also does not work, in the following situation: - You're using a pre-compiled external toolchain, so host-binutils is not selected/enabled, so the version selection in package/binutils/Config.in.host is not used, and therefore BR2_BINUTILS_VERSION_ARC cannot be set to 'y'. - You have binutils enabled for the target. Then, with your patch, we will no longer select the ARC-specific fork of binutils. Basically, for the target binutils (just like for target gdb), we don't have any version selection, so we force using one specific version depending on the architecture. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH 2/3] binutils/ARC: move ARC specific code together
On Fri, 6 Dec 2019 11:39:23 -0800 Vineet Gupta wrote: > That way ARC specific version update needs to be done in 1 place only > > Signed-off-by: Vineet Gupta > --- > package/binutils/binutils.mk | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk > index a19d6940f7c1..ecc78b81e59f 100644 > --- a/package/binutils/binutils.mk > +++ b/package/binutils/binutils.mk > @@ -8,14 +8,11 @@ > # If not, we do like other packages > BINUTILS_VERSION = $(call qstrip,$(BR2_BINUTILS_VERSION)) > ifeq ($(BINUTILS_VERSION),) > -ifeq ($(BR2_arc),y) > -BINUTILS_VERSION = arc-2019.09-rc1 > -else > BINUTILS_VERSION = 2.32 > endif > -endif # BINUTILS_VERSION > > -ifeq ($(BINUTILS_VERSION),arc-2019.09-rc1) > +ifeq ($(BR2_arc),y) This is not going to work well with your PATCH 3/3 (on which I have comments). Indeed, BR2_arc=y does not necessarily imply that we want to use the ARC-specific binutils version. You can however use ifeq ($(BR2_BINUTILS_VERSION_ARC),y) instead. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH 1/3] toolchain, glibc: Allow ARC big endian glibc builds
On Fri, 6 Dec 2019 11:39:22 -0800 Vineet Gupta wrote: > From: Vineet Gupta > > Apparently big endian glibc builds just work, if we let the endian > header allow that (which prev was #error). > > The current ARC glibc version in buildroot arc-2019.09-rc1 already > contains that fix. > > Signed-off-by: Vineet Gupta > --- > toolchain/toolchain-buildroot/Config.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to master with an improved commit title/log. Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH v2 1/1] arch/config.in.arc: Introduce the ARC optimized hs38 config
On Tue, 12 Nov 2019 07:34:43 -0800 Vineet Gupta wrote: > This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier) > > Signed-off-by: Vineet Gupta > --- > Changes since v1 > - Retained BR2_hs38 build semantics (dropped BR2_archs) > - Introduced BR2_hs38_64mpy for generating double multiply instructions > --- > arch/Config.in.arc | 17 - > 1 file changed, 12 insertions(+), 5 deletions(-) Applied to next, thanks. Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH 2/3] arch/config.in.arc: Introduce ARC ISA toggle to ease downstream toggles
Hello, On Fri, 8 Nov 2019 09:41:11 -0800 Vineet Gupta wrote: > Signed-off-by: Vineet Gupta > --- > arch/Config.in.arc | 25 +++-- > 1 file changed, 23 insertions(+), 2 deletions(-) > > diff --git a/arch/Config.in.arc b/arch/Config.in.arc > index 284951b82cee..dbc608db39c6 100644 > --- a/arch/Config.in.arc > +++ b/arch/Config.in.arc > @@ -1,3 +1,18 @@ > +choice > + prompt "Target ISA" > + default BR2_arcompact > + depends on BR2_arc > + help > + Specific ARC ISA to use > + > +config BR2_arcompact > + bool "ARCompact ISA" > + > +config BR2_arcv2 > + bool "ARCv2 ISA" > + > +endchoice I don't think we want a choice for that. It should simply be implied by the target CPU selection. So instead, do it like this: config BR2_ARC_ARCH_ISA_ARCOMPACT bool config BR2_ARC_ARCH_ISA_ARCV2 bool (note: the names are just a proposal, there are probably some better names) > choice > prompt "Target CPU" > default BR2_arc770d > @@ -7,12 +22,15 @@ choice > > config BR2_arc750d > bool "ARC 750D" > + depends on BR2_arcompact Replace by: select BR2_ARC_ARCH_ISA_ARCOMPACT > > config BR2_arc770d > bool "ARC 770D" > + depends on BR2_arcompact Ditto. > > config BR2_archs > bool "ARC HS38" > + depends on BR2_arcv2 select BR2_ARC_ARCH_ISA_ARCV2 > help > Generic ARC HS capable of running Linux, i.e. with MMU, > caches and 32-bit multiplier. Also it corresponds to the default > @@ -20,6 +38,7 @@ config BR2_archs > > config BR2_archs38 > bool "ARC HS38 with 64-bit mpy" > + depends on BR2_arcv2 select BR2_ARC_ARCH_ISA_ARCV2 > help > Fully featured ARC HS capable of running Linux, i.e. with MMU, > caches and 64-bit multiplier. > @@ -29,6 +48,7 @@ config BR2_archs38 > > config BR2_archs38_full > bool "ARC HS38 with Quad MAC & FPU" > + depends on BR2_arcv2 select BR2_ARC_ARCH_ISA_ARCV2 > help > Fully featured ARC HS with additional support for > - Dual- and quad multiply and MC oprations > @@ -39,6 +59,7 @@ config BR2_archs38_full > > config BR2_archs4x_rel31 > bool "ARC HS48 rel 31" > + depends on BR2_arcv2 select BR2_ARC_ARCH_ISA_ARCV2 > help > Latest release of HS48 processor > - Dual- and quad multiply and MC oprations > @@ -72,8 +93,8 @@ config BR2_GCC_TARGET_CPU > default "hs4x_rel31" if BR2_archs4x_rel31 > > config BR2_READELF_ARCH_NAME > - default "ARCompact" if BR2_arc750d || BR2_arc770d > - default "ARCv2" if BR2_archs || BR2_archs38 || BR2_archs38_full > || BR2_archs4x_rel31 > + default "ARCompact" if BR2_arcompact default "ARCompact" if BR2_ARC_ARCH_ISA_ARCOMPACT > + default "ARCv2" if BR2_arcv2 default "ARCv2" if BR2_ARC_ARCH_ISA_ARCV2 Thanks, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [Buildroot] [PATCH 1/3] arch/config.in.arc: Introduce the ARC optimized hs38 config
Hello, +Arnout for legacy handling. On Fri, 8 Nov 2019 09:41:10 -0800 Vineet Gupta wrote: > This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier) > > Signed-off-by: Vineet Gupta > --- > arch/Config.in.arc | 21 ++--- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/arch/Config.in.arc b/arch/Config.in.arc > index c65bb01f1f4f..284951b82cee 100644 > --- a/arch/Config.in.arc > +++ b/arch/Config.in.arc > @@ -11,13 +11,19 @@ config BR2_arc750d > config BR2_arc770d > bool "ARC 770D" > > -config BR2_archs38 > +config BR2_archs > bool "ARC HS38" > help > Generic ARC HS capable of running Linux, i.e. with MMU, > - caches and multiplier. Also it corresponds to the default > + caches and 32-bit multiplier. Also it corresponds to the default > configuration in older GNU toolchain versions. > > +config BR2_archs38 This re-use of an existing name is a bit annoying. Indeed, all existing users of Buildroot that have a configuration with BR2_archs38 will now be building for a ARC system with a 64-bit multiplier, while they were previously building for a 32-bit multiplier. I see that what you have done is to try to be consistent between the BR2_ options and the gcc options. I'm hesitating between keeping the consistency but making the migration a bit annoying for users, or breaking the consistency to make the migration smooth for users. Since I think the number of affected users will probably be quite small/limited, I think I would be fine with merging your patch as-is, but I'd like to hear from others. Thanks, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello, On Wed, 1 Mar 2017 21:30:31 +, Alexey Brodkin wrote: > Speaking of "defconfigs" I really meant something that we may use > for building our toolchain outside of Buildroot if we want something that > differs from uClibc's defaults/defconfig - and most probably we'll need > something > either to add to uClibc's minimal_defconfig or exclude from > _maximal_defconfig. > > Otherwise how may we be in control of libc in our "reference" toolchain? A defconfig is what it is: a configuration provided as an example. Nothing forces you to use it. It's just an example. Buildroot doesn't use any of the uClibc-ng defconfigs. Buildroot has its own configuration for uClibc. You could just do the same for your reference toolchain. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello, On Wed, 1 Mar 2017 18:25:35 +, Alexey Brodkin wrote: > That means for building of our toolchain we'll need to have > separately stored "defconfigs" in some form. Let's see what Anton says on > that :) > > And regardless of what mr Anton says having off-the-tree defconfigs is not > the best idea > because with time options will go in and out and occasionally we'll have > outdated > defconfigs. What would they be off-tree? What I meant is that when you look at the per architecture defconfigs, they are also all exactly the same, except for the TARGET_ option. So instead of having this big duplication, my suggestion is to get rid of architecture-specific defconfig, and just have a few architecture-independent defconfig, addressing common use cases (such as "minimal" and "feature full"). Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello, On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote: > This commit enables getpt() support in ARC defconfigs as some packages > need it. E.g. we need this to be able to build xterm package as it uses > getpt(). > > As an example I can refer to buildroot autobuilds where xterm build is > failing when using prebuilt ARC toolchain (which in its turn uses uClibc > without getpt() support): > http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3fe8ad642/build-end.log > > Signed-off-by: Vlad Zakharov <vzak...@synopsys.com> > --- > extra/Configs/defconfigs/arc/arcv2_defconfig | 1 + > extra/Configs/defconfigs/arc/defconfig | 1 + > 2 files changed, 2 insertions(+) That's more of a question for Waldemar: does it really makes sense to have defconfigs for each architecture? I mean how do they differ between each other? For example, the ARC arcv2_defconfig and defconfig only differ by the option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs. Shouldn't be the solution used on ARM (removing all options to select the compiler flags, and leave it to the user to pass the appropriate options) be used as well ? So, are they really useful? Shouldn't uclibc-ng instead come with just one or two defconfigs, like a "minimal" one and "full-featured" one? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Build regressions/improvements in v4.9-rc1
Hello, On Thu, 27 Oct 2016 09:07:55 +, Alexey Brodkin wrote: > > axs101 is using a 770 core, while the toolchain is built for the HS38 > > core. I'm somewhat surprised that a single ARC toolchain cannot produce > > code for both 770 and HS38, but it seems to be the case. > > > > So you need a separate toolchain for ARC770. > > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core > which has ARCv2 ISA (binary incompatible with ARCompact). > > Essentially both gcc and binutils will happily build for both architectures > given > proper options were passed on the command line. But Linux kernel gets linked > with > pre-built libgcc (it is a part of toolchain). And so it all boils down to a > requirement > to have multilibbed uClibc toolchain. Which we don't have. Interesting. Why is libgcc linked with the kernel on ARC? I don't think that's the case on other architectures: the kernel is freestanding and provides everything that it needs without relying on the compiler runtime. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Build regressions/improvements in v4.9-rc1
Hello, On Thu, 27 Oct 2016 11:32:11 +0200, Arnd Bergmann wrote: > A couple of other architectures do this as well: > > $ git grep -w LIBGCC arch/*/Makefile > arch/arc/Makefile:LIBGCC:= $(shell $(CC) $(cflags-y) > --print-libgcc-file-name) > arch/arc/Makefile:libs-y+= arch/arc/lib/ $(LIBGCC) > arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) > -print-file-name=libgcc.a) > arch/cris/Makefile:libs-y += arch/cris/$(SARCH)/lib/ $(LIBGCC) > arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/hexagon/Makefile:libs-y += $(LIBGCC) > arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/m32r/Makefile:libs-y += arch/m32r/lib/ $(LIBGCC) > arch/nios2/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > $(KCFLAGS) -print-libgcc-file-name) > arch/nios2/Makefile:libs-y += arch/nios2/lib/ $(LIBGCC) > arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/openrisc/Makefile:libs-y += $(LIBGCC) > arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/parisc/Makefile:libs-y += arch/parisc/lib/ $(LIBGCC) > arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/xtensa/Makefile:libs-y += arch/xtensa/lib/ $(LIBGCC) > > It's also not always freestanding on the architectures that don't > include libgcc: > > $ git grep ffreestanding arch/ > arch/mips/Makefile:cflags-y += -ffreestanding > arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call > cc-option,-ffreestanding) > arch/score/Makefile:-D__linux__ -ffunction-sections -ffreestanding > arch/sh/Makefile:cflags-y += $(isaflags-y) -ffreestanding > arch/x86/Makefile:KBUILD_CFLAGS += -ffreestanding # temporary until > string.h is fixed > arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__ > > (xtensa being the only one that apparently uses libgcc *and* passes > -ffreestanding, for whatever reasons). > > The other architectures tend to implement the parts of libgcc that they > need in the kernel. Thanks for the details, good to know! Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Build regressions/improvements in v4.9-rc1
Hello, On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote: > > Hm... that's strange - it used to work but doesn't work with newer > > Buildroot... > > > > Anyways if something very simple (i.e. with no extra libraries) works for > > you just go > > ahead and grab pre-built image that Thomas Petazzoni builds. > > > > That's the most recent one: > > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2 > > > > Thanks, I grabbed that and it works for axs103_smp_defconfig: > > http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/ > > > It doesn't work for axs101_defconfig, saying: > > arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds. > Stop. axs101 is using a 770 core, while the toolchain is built for the HS38 core. I'm somewhat surprised that a single ARC toolchain cannot produce code for both 770 and HS38, but it seems to be the case. So you need a separate toolchain for ARC770. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Build regressions/improvements in v4.9-rc1
Hello, On Wed, 19 Oct 2016 12:23:12 +, Alexey Brodkin wrote: > > I tried building a new toolchain with buildroot, using the instructions > > from last time, but the resulting toolchain doesn't relocate, ie. it has > > hard-coded paths in it. Any ideas? > > Hm... that's strange - it used to work but doesn't work with newer > Buildroot... > > Anyways if something very simple (i.e. with no extra libraries) works for you > just go > ahead and grab pre-built image that Thomas Petazzoni builds. > > That's the most recent one: > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2 > > If I'm not mistaken Thomas runs some post-processing script to make these > toolchains > relocatable. > > Maybe Thomas may comment on that and even maybe will share his > post-processing technique > so you'll be able to build your customized toolchain. I simply have two patches on top of Buildroot to build the toolchains available at http://autobuild.buildroot.org/toolchains/tarballs/ : - One patch that builds mpc, gmp and mpfr statically. This is needed since the host tools are built with an absolute rpath, so once the toolchain is moved, it can't find the host shared libraries that have been built for it. Using static linking is a temporary work-around, our idea is to fix the rpath to use relative path using $ORIGIN. There are some patches from Samuel Martin doing this, we have discussed them during the Buildroot Developers Meeting last week-end, and we proposed to Samuel to investigate a slightly different approach (namely add more features to the upstream patchelf utility). - One patch that fixes the toolchain wrapper logic so that it works fine when the toolchain is moved out of the usr/ sub-directory. We started discussing it during the meeting, but I got drowned into other discussions, so we haven't had the time to get to the bottom of it. If people are interested, I can prepare a tutorial on how to build re-usable and relocatable toolchains with Buildroot. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
