| Submitter | Kumar Gala |
|---|---|
| Date | Aug. 1, 2011, 2:21 p.m. |
| Message ID | <1312208500-13381-1-git-send-email-galak@kernel.crashing.org> |
| Download | mbox | patch |
| Permalink | /patch/8969/ |
| State | New, archived |
| Headers | show |
Comments
On Mon, 2011-08-01 at 09:21 -0500, Kumar Gala wrote: > Added a ${GCC_EXTRA_OECONF} to the the building up of gcc's > ${EXTRA_OECONF}. This is similar to what we have in the glibc recipe > files. > > This allows for a tune file to add something like: > > GCC_EXTRA_OECONF += "--with-cpu=e5500" > > If needed. > > Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Why is that desirable? From the looks of that patch it will affect gcc-cross as well as target gcc and, if you're going to do this, I think you need to find some way to disambiguate the resulting compilers. Otherwise there is going to be no way to predict what options ${CC} was built with. Even for the on-target gcc case, if you are going to start putting MACHINE-specific variables into the configure commandline then you need to make sure that the output packages have an appropriate Architecture. I don't think that's going to be the case at the moment. p.
On Aug 1, 2011, at 9:30 AM, Phil Blundell wrote: > On Mon, 2011-08-01 at 09:21 -0500, Kumar Gala wrote: >> Added a ${GCC_EXTRA_OECONF} to the the building up of gcc's >> ${EXTRA_OECONF}. This is similar to what we have in the glibc recipe >> files. >> >> This allows for a tune file to add something like: >> >> GCC_EXTRA_OECONF += "--with-cpu=e5500" >> >> If needed. >> >> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> > > Why is that desirable? From the looks of that patch it will affect > gcc-cross as well as target gcc and, if you're going to do this, I think > you need to find some way to disambiguate the resulting compilers. > Otherwise there is going to be no way to predict what options ${CC} was > built with. Its desirable to get a consistent set of tools. For example it means the cross toolchain in an ADT will target the given processor it was built with w/o having to explicit set flags to gcc. Additionally, it might be useful for building multilib gcc on powerpc that seems to need --with-cpu-32 --with-cpu-64. Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: ppc64e5500-poky-linux-gcc > Even for the on-target gcc case, if you are going to start putting > MACHINE-specific variables into the configure commandline then you need > to make sure that the output packages have an appropriate Architecture. > I don't think that's going to be the case at the moment. I'm open to solutions to my problem, but need to find someway to pass '--with-cpu=' to configure. - k
On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
The thing about disambiguating was that, if you're going to modify the
configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
to consider what happens if you have a single build directory that's
being used for multiple MACHINEs.
From what you've described as the usecase for this feature it sounds as
though the easiest answer to that is simply to stop your extra flags
from being used by gcc-cross and ensure that they're only used by gcc.
Then you'd just need to make sure that the PACKAGE_ARCH for gcc always
reflects the options being used, which sounds lke it might already be
true for ppc but possibly is not in general. (The target gcc package
isn't buildable for me at the moment but a bit of poking around with
bitbake -e suggests that it's just getting the generic architecture
PACKAGE_ARCH on i586 at least.)
I'm not familiar enough with the sdk code to know whether there are
going to be any issues around that or not.
p.
On 08/01/2011 09:07 AM, Phil Blundell wrote: > On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: >> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: > > The thing about disambiguating was that, if you're going to modify the > configure opts for gcc-cross based (indirectly) on ${MACHINE} you need > to consider what happens if you have a single build directory that's > being used for multiple MACHINEs. What, I think, Kumar is driving at is why are you saying MACHINE when it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500
On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: > On 08/01/2011 09:07 AM, Phil Blundell wrote: > > On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: > >> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: > > > > The thing about disambiguating was that, if you're going to modify the > > configure opts for gcc-cross based (indirectly) on ${MACHINE} you need > > to consider what happens if you have a single build directory that's > > being used for multiple MACHINEs. > > What, I think, Kumar is driving at is why are you saying MACHINE when > it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 The question is whether we'd like to get to the point of having more toolchains or less toolchains. I'd personally like to get to the point of less toolchains (e.g. one per arch) rather than more of them. We already pass all the appropriate flags around in the ADT/sdk code and in our own cross builds, we could easily add those to the default target environment too. This would actually make it clearer what is going on to the end user too rather than hiding the details into the gcc compilation. So all things considered, I don't think this is the best way to go... Cheers, Richard
On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: > On 08/01/2011 09:07 AM, Phil Blundell wrote: > > On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: > >> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: > > > > The thing about disambiguating was that, if you're going to modify the > > configure opts for gcc-cross based (indirectly) on ${MACHINE} you need > > to consider what happens if you have a single build directory that's > > being used for multiple MACHINEs. > > What, I think, Kumar is driving at is why are you saying MACHINE when > it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 I said MACHINE because, in general, it's the MACHINE which selects the tune. If it's the case that (for powerpc at least) all the tunes end up setting a distinct PACKAGE_ARCH then this probably is a non-issue there, but that isn't true in the general case. (For example, the arm926ejs tune file sets PACKAGE_ARCH=armv5te or something, so it wouldn't be sensible for it to be configuring gcc --with-cpu=arm926ej-s.) Likewise for gcc-cross, if you're going to let this apply there then you need to make sure that the TARGET_ARCH value in the triplet is at least as specific as the tuning you ask for, otherwise you will end up with multiple different compilers all called armv5te-oe-linux-gcc or whatever. p.
On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote: > On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: >> On 08/01/2011 09:07 AM, Phil Blundell wrote: >>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: >>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: >>> >>> The thing about disambiguating was that, if you're going to modify the >>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need >>> to consider what happens if you have a single build directory that's >>> being used for multiple MACHINEs. >> >> What, I think, Kumar is driving at is why are you saying MACHINE when >> it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 > > The question is whether we'd like to get to the point of having more > toolchains or less toolchains. I'd personally like to get to the point > of less toolchains (e.g. one per arch) rather than more of them. We > already pass all the appropriate flags around in the ADT/sdk code and in > our own cross builds, we could easily add those to the default target > environment too. This would actually make it clearer what is going on to > the end user too rather than hiding the details into the gcc > compilation. > > So all things considered, I don't think this is the best way to go... > How is this done or exported to the user of an ADT/sdk toolchain? - k
On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote: > On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote: > > > On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: > >> On 08/01/2011 09:07 AM, Phil Blundell wrote: > >>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: > >>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: > >>> > >>> The thing about disambiguating was that, if you're going to modify the > >>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need > >>> to consider what happens if you have a single build directory that's > >>> being used for multiple MACHINEs. > >> > >> What, I think, Kumar is driving at is why are you saying MACHINE when > >> it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 > > > > The question is whether we'd like to get to the point of having more > > toolchains or less toolchains. I'd personally like to get to the point > > of less toolchains (e.g. one per arch) rather than more of them. We > > already pass all the appropriate flags around in the ADT/sdk code and in > > our own cross builds, we could easily add those to the default target > > environment too. This would actually make it clearer what is going on to > > the end user too rather than hiding the details into the gcc > > compilation. > > > > So all things considered, I don't think this is the best way to go... > > > > How is this done or exported to the user of an ADT/sdk toolchain? There is a script included in the toolchain tarball which contains the appropriate information. I don't have one handy to check but I suspect Jessica will have. Jessica? Cheers, Richard
On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote: > On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote: >> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote: >> >>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: >>>> On 08/01/2011 09:07 AM, Phil Blundell wrote: >>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: >>>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: >>>>> >>>>> The thing about disambiguating was that, if you're going to modify the >>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need >>>>> to consider what happens if you have a single build directory that's >>>>> being used for multiple MACHINEs. >>>> >>>> What, I think, Kumar is driving at is why are you saying MACHINE when >>>> it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 >>> >>> The question is whether we'd like to get to the point of having more >>> toolchains or less toolchains. I'd personally like to get to the point >>> of less toolchains (e.g. one per arch) rather than more of them. We >>> already pass all the appropriate flags around in the ADT/sdk code and in >>> our own cross builds, we could easily add those to the default target >>> environment too. This would actually make it clearer what is going on to >>> the end user too rather than hiding the details into the gcc >>> compilation. >>> >>> So all things considered, I don't think this is the best way to go... >>> >> >> How is this done or exported to the user of an ADT/sdk toolchain? > > There is a script included in the toolchain tarball which contains the > appropriate information. I don't have one handy to check but I suspect > Jessica will have. Jessica? > Ping on this script? - k
On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote: > > On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote: > >> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: >>> On 08/01/2011 09:07 AM, Phil Blundell wrote: >>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: >>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: >>>> >>>> The thing about disambiguating was that, if you're going to modify the >>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need >>>> to consider what happens if you have a single build directory that's >>>> being used for multiple MACHINEs. >>> >>> What, I think, Kumar is driving at is why are you saying MACHINE when >>> it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 >> >> The question is whether we'd like to get to the point of having more >> toolchains or less toolchains. I'd personally like to get to the point >> of less toolchains (e.g. one per arch) rather than more of them. We >> already pass all the appropriate flags around in the ADT/sdk code and in >> our own cross builds, we could easily add those to the default target >> environment too. This would actually make it clearer what is going on to >> the end user too rather than hiding the details into the gcc >> compilation. >> >> So all things considered, I don't think this is the best way to go... >> > > How is this done or exported to the user of an ADT/sdk toolchain? I still dont understand the concern here. GCC is already picking a default for -mcpu, so why is having a tune file pick a better default any issue? If there is an explicit -mcpu or other options like -mtune, the setting of --with-cpu will get ignored. - k
On Mon, 2011-08-08 at 11:35 -0500, Kumar Gala wrote: > On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote: > > > > > On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote: > > > >> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: > >>> On 08/01/2011 09:07 AM, Phil Blundell wrote: > >>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: > >>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: > >>>> > >>>> The thing about disambiguating was that, if you're going to modify the > >>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need > >>>> to consider what happens if you have a single build directory that's > >>>> being used for multiple MACHINEs. > >>> > >>> What, I think, Kumar is driving at is why are you saying MACHINE when > >>> it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 > >> > >> The question is whether we'd like to get to the point of having more > >> toolchains or less toolchains. I'd personally like to get to the point > >> of less toolchains (e.g. one per arch) rather than more of them. We > >> already pass all the appropriate flags around in the ADT/sdk code and in > >> our own cross builds, we could easily add those to the default target > >> environment too. This would actually make it clearer what is going on to > >> the end user too rather than hiding the details into the gcc > >> compilation. > >> > >> So all things considered, I don't think this is the best way to go... > >> > > > > How is this done or exported to the user of an ADT/sdk toolchain? > > I still dont understand the concern here. GCC is already picking a > default for -mcpu, so why is having a tune file pick a better default > any issue? > > If there is an explicit -mcpu or other options like -mtune, the > setting of --with-cpu will get ignored. There are two sides to this: a) In the ppc case there isn't that much of an issue since the different tunes tend to have their own very specific package architectures. It likely therefore doesn't matter much if gcc is hardcoded to a given default. It would matter more on certain arm combinations I can think of depending on what got hardcoded as default. b) There are very few circumstances you'd ever be in an environment where the correct cpu flags weren't getting supplied (and we have sanity checks to ensure they do). We want to be heading to wards less toolchains, not more toolchains and the more we code into the toolchain, the more different toolchain builds we'll need. Whilst I can see the reason for wanting a), I worry it will mask issues where the flags are missing and also cause more toolchain fragmentation with people very likely to get the values wrong in the arm case. I'm therefore reluctant. Cheers, Richard
On Mon, 2011-08-08 at 11:32 -0500, Kumar Gala wrote: > On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote: > > > On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote: > >> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote: > >> > >>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote: > >>>> On 08/01/2011 09:07 AM, Phil Blundell wrote: > >>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote: > >>>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like: > >>>>> > >>>>> The thing about disambiguating was that, if you're going to modify the > >>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need > >>>>> to consider what happens if you have a single build directory that's > >>>>> being used for multiple MACHINEs. > >>>> > >>>> What, I think, Kumar is driving at is why are you saying MACHINE when > >>>> it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500 > >>> > >>> The question is whether we'd like to get to the point of having more > >>> toolchains or less toolchains. I'd personally like to get to the point > >>> of less toolchains (e.g. one per arch) rather than more of them. We > >>> already pass all the appropriate flags around in the ADT/sdk code and in > >>> our own cross builds, we could easily add those to the default target > >>> environment too. This would actually make it clearer what is going on to > >>> the end user too rather than hiding the details into the gcc > >>> compilation. > >>> > >>> So all things considered, I don't think this is the best way to go... > >>> > >> > >> How is this done or exported to the user of an ADT/sdk toolchain? > > > > There is a script included in the toolchain tarball which contains the > > appropriate information. I don't have one handy to check but I suspect > > Jessica will have. Jessica? > > > > Ping on this script? I have a build handy so here is the 32 bit toolchain which runs on 64 bit systems for x86: $ cat environment-setup-i586-poky-linux export PATH=/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH export PKG_CONFIG_SYSROOT_DIR=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux export PKG_CONFIG_PATH=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux/usr/lib/pkgconfig export CONFIG_SITE=/opt/poky/1.0+snapshot/site-config-i586-poky-linux export CC=i586-poky-linux-gcc export CXX=i586-poky-linux-g++ export GDB=i586-poky-linux-gdb export TARGET_PREFIX=i586-poky-linux- export CONFIGURE_FLAGS="--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux" export CFLAGS=" -m32 -march=i586 --sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux" export CXXFLAGS=" -m32 -march=i586 --sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux" export LDFLAGS="--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux" export CPPFLAGS="--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux" export OECORE_NATIVE_SYSROOT="/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux" export OECORE_TARGET_SYSROOT="/opt/poky/1.0+snapshot/sysroots/i586-poky-linux" export OECORE_ACLOCAL_OPTS="-I /opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" export POKY_DISTRO_VERSION="1.0+snapshot-20110802" You can see it captures the correct CFLAGS etc. Cheers, Richard
Patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc index 4c1e1e1..b054266 100644 --- a/meta/recipes-devtools/gcc/gcc-4.6.inc +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc @@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r2" +PR = "r3" # Third digit in PV should be incremented after a minor release # happens from this branch on gcc e.g. currently its 4.6.0 diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc index 9f5ba33..aac6d69 100644 --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc @@ -20,6 +20,7 @@ LANGUAGES ?= "c,c++${FORTRAN}${JAVA}" SPECIAL_ARCH_LIST = "powerpc" OPTSPACE = ${@base_contains("SPECIAL_ARCH_LIST", "${TARGET_ARCH}", "", "--enable-target-optspace",d)} +GCC_EXTRA_OECONF ?= "" EXTRA_OECONF_BASE ?= "" EXTRA_OECONF_PATHS ?= "" EXTRA_OECONF_INITIAL ?= "" @@ -39,6 +40,7 @@ EXTRA_OECONF = "${@['--enable-clocale=generic', ''][bb.data.getVar('USE_NLS', d, --enable-libstdcxx-pch \ --program-prefix=${TARGET_PREFIX} \ ${OPTSPACE} \ + ${GCC_EXTRA_OECONF} \ ${EXTRA_OECONF_BASE} \ ${EXTRA_OECONF_FPU} \ ${EXTRA_OECONF_PATHS} \ diff --git a/meta/recipes-devtools/gcc/gcc_4.5.1.bb b/meta/recipes-devtools/gcc/gcc_4.5.1.bb index 12e42c4..f036cb1 100644 --- a/meta/recipes-devtools/gcc/gcc_4.5.1.bb +++ b/meta/recipes-devtools/gcc/gcc_4.5.1.bb @@ -1,4 +1,4 @@ -PR = "r7" +PR = "r8" require gcc-${PV}.inc require gcc-configure-target.inc require gcc-package-target.inc diff --git a/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb b/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb index 2df12ef..9fd2b0a 100644 --- a/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb +++ b/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb @@ -1,4 +1,4 @@ -PR = "r4" +PR = "r5" require gcc-${PV}.inc require gcc-configure-target.inc
Added a ${GCC_EXTRA_OECONF} to the the building up of gcc's ${EXTRA_OECONF}. This is similar to what we have in the glibc recipe files. This allows for a tune file to add something like: GCC_EXTRA_OECONF += "--with-cpu=e5500" If needed. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> --- meta/recipes-devtools/gcc/gcc-4.6.inc | 2 +- meta/recipes-devtools/gcc/gcc-configure-common.inc | 2 ++ meta/recipes-devtools/gcc/gcc_4.5.1.bb | 2 +- meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-)