Message ID | 884EA965490E3C4D8E66AEF41E98025006BF23@ezex10.ezchip.com |
---|---|
State | Superseded |
Headers | show |
Dear Noam Camus, On Sun, 23 Feb 2014 08:28:21 +0000, Noam Camus wrote: > When the toolchain is custom we can denote that by setting in the triplet the vendor part. > This is done through configution, where the default is buildroot. > > Signed-off-by: Noam Camus <noamc@ezchip.com> Is there a compelling reason to allow the configuration of the vendor part of the tuple? To me, it makes sense that all Buildroot toolchain have the "buildroot" vendor, so that they can be identified easily. Also, if by mistake the vendor part of the tuple is defined by the user as "unknown", they he might get compilation issues when building with target architecture == host architecture. See 11017f081fc5b034e680d89eaea729c19f450e01 ('pkg-infra: make sure cross compiling is enabled when host == target'). Thomas
Hi Thomas, Here (EZchip) we change toolchain elements such binutils/gdb kernel (headers) and gcc. We are using override feature of buildroot to create our custom buildroot toolchain. One of the GCC changes we carry is that we assume dedicated vendor (ezchip) to control several GCC defaults and enable extra configurations within GCC. About "unknown" I guess that it can be blocked by checking the value and in some cases cause intentional make error. I hope this makes sense to you. Noam -----Original Message----- From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] Sent: Sunday, February 23, 2014 11:47 AM To: Noam Camus Cc: buildroot@busybox.net Subject: Re: [Buildroot] [PATCH] toolchain: control GNU_TARGET_NAME vendor part Dear Noam Camus, On Sun, 23 Feb 2014 08:28:21 +0000, Noam Camus wrote: > When the toolchain is custom we can denote that by setting in the triplet the vendor part. > This is done through configution, where the default is buildroot. > > Signed-off-by: Noam Camus <noamc@ezchip.com> Is there a compelling reason to allow the configuration of the vendor part of the tuple? To me, it makes sense that all Buildroot toolchain have the "buildroot" vendor, so that they can be identified easily. Also, if by mistake the vendor part of the tuple is defined by the user as "unknown", they he might get compilation issues when building with target architecture == host architecture. See 11017f081fc5b034e680d89eaea729c19f450e01 ('pkg-infra: make sure cross compiling is enabled when host == target'). Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Dear Noam Camus, (Please do not top post. It would also be nice if you used a mail client that wrapped lines at a reasonable length.) On Sun, 23 Feb 2014 11:45:46 +0000, Noam Camus wrote: > Here (EZchip) we change toolchain elements such binutils/gdb kernel (headers) and gcc. > We are using override feature of buildroot to create our custom buildroot toolchain. > One of the GCC changes we carry is that we assume dedicated vendor (ezchip) to control several GCC defaults and enable extra configurations within GCC. Hum, ok. Is the vendor part of the tuple meant to be used this way? > About "unknown" I guess that it can be blocked by checking the value and in some cases cause intentional make error. > > I hope this makes sense to you. Right. I guess we can make this configurable. However, your patch has some issues: * It only creates the option BR2_TOOLCHAIN_BUILDROOT_VENDOR in the internal toolchain backend. But GNU_TARGET_NAME is also used with the external toolchain backend, which means in the external toolchain case we would end up with a GNU_TARGET_NAME having an empty vendor part of the tuple. * The new Config.in option lacks an help text, and the help text should explain in detail how this should be used, and in which situations. Also the title of the help text should be just "custom toolchain vendor name". Thanks! Thomas
diff --git a/package/Makefile.in b/package/Makefile.in index eea7043..38d8416 100644 --- a/package/Makefile.in +++ b/package/Makefile.in @@ -20,8 +20,10 @@ endif MAKE1:=$(HOSTMAKE) -j1 MAKE:=$(HOSTMAKE) $(if $(PARALLEL_JOBS),-j$(PARALLEL_JOBS)) +VENDOR:=$(call qstrip,$(BR2_TOOLCHAIN_BUILDROOT_VENDOR)) + # Compute GNU_TARGET_NAME -GNU_TARGET_NAME=$(ARCH)-buildroot-$(TARGET_OS)-$(LIBC)$(ABI) +GNU_TARGET_NAME=$(ARCH)-$(VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI) # Blackfin FLAT needs uclinux ifeq ($(BR2_bfin)$(BR2_BINFMT_FLAT),yy) diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in index cd88889..d1760dd 100644 --- a/toolchain/toolchain-buildroot/Config.in +++ b/toolchain/toolchain-buildroot/Config.in @@ -69,6 +69,10 @@ config BR2_TOOLCHAIN_BUILDROOT_LIBC default "glibc" if BR2_TOOLCHAIN_BUILDROOT_EGLIBC default "glibc" if BR2_TOOLCHAIN_BUILDROOT_GLIBC +config BR2_TOOLCHAIN_BUILDROOT_VENDOR + string "custom buildroot toolchain vendor name" + default "buildroot" + source "package/uclibc/Config.in" source "package/binutils/Config.in.host"
When the toolchain is custom we can denote that by setting in the triplet the vendor part. This is done through configution, where the default is buildroot. Signed-off-by: Noam Camus <noamc@ezchip.com> --- package/Makefile.in | 4 +++- toolchain/toolchain-buildroot/Config.in | 4 ++++ 2 files changed, 7 insertions(+), 1 deletions(-) -- 1.7.1