package/Makefile.in: remove HOSTCC_VERSION
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
HOSTCC_VERSION is no longer used since gcc switched to the package infrastructure in e236fe481. It was in fact no longer needed since we dropped support for gcc 4.3.
---
Note that we currently claim to support system gcc >= 2.95, but I don't think that matches reality...
--- package/Makefile.in | 4 ---- 1 file changed, 4 deletions(-)
package/Makefile.in +0 -4
@@ -219,10 +219,6 @@ HOST_CFLAGS += $(HOST_CPPFLAGS) HOST_CXXFLAGS += $(HOST_CFLAGS) HOST_LDFLAGS += -L$(HOST_DIR)/lib -L$(HOST_DIR)/usr/lib -Wl,-rpath,$(HOST_DIR)/usr/lib -# hostcc version as an integer - E.G. 4.3.2 => 432 -HOSTCC_VERSION := $(shell $(HOSTCC_NOCCACHE) --version | \ - sed -n 's/^.* \([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)[ ]*.*$$/\1\2\3/p') - # host-intltool should be executed with the system perl, so we save # the path to the system perl, before a host-perl built by Buildroot # might get installed into $(HOST_DIR)/usr/bin and therefore appears
Signature · 1 line
2.6.2
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
Quoted 5 lines · Arnout Vandecappelle (Essensium/Mind)
HOSTCC_VERSIONis no longer used since gcc switched to the package infrastructure ine236fe481. It was in fact no longer needed since we dropped support for gcc 4.3.
I just now notice that this patch is not really for master but for next, while
the other two are for master...
Regards,
Arnout
Quoted 23 lines
---
Note that we currently claim to support system gcc >= 2.95, but I don't think that matches reality...--- package/Makefile.in | 4 ---- 1 file changed, 4 deletions(-)package/Makefile.in +0
-4@@ -219,10 +219,6 @@ HOST_CFLAGS += $(HOST_CPPFLAGS) HOST_CXXFLAGS += $(HOST_CFLAGS) HOST_LDFLAGS += -L$(HOST_DIR)/lib -L$(HOST_DIR)/usr/lib -Wl,-rpath,$(HOST_DIR)/usr/lib -# hostcc version as an integer - E.G. 4.3.2 => 432 -HOSTCC_VERSION := $(shell $(HOSTCC_NOCCACHE) --version | \ - sed -n 's/^.* \([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)[ ]*.*$$/\1\2\3/p') - # host-intltool should be executed with the system perl, so we save # the path to the system perl, before a host-perl built by Buildroot # might get installed into $(HOST_DIR)/usr/bin and therefore appears
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 2/3 Config.in: add symbols for BR2_HOST_GCC_AT_LEAST_X_Y
In reply to Arnout Vandecappelle (Essensium/Mind)Some host packages need a recent gcc version. Add symbols to Config.in to specify the HOSTCC version. The values are passed through the environment, and this environment is generated in a new support script.
Also update the documentation to mention the new symbols.
--- Config.in | 17 ++++++++++ Makefile | 1 + docs/manual/adding-packages-directory.txt | 7 ++++ support/scripts/gcc-version-variables | 56 +++++++++++++++++++++++++++++++ 4 files changed, 81 insertions(+) create mode 100755 support/scripts/gcc-version-variables
Config.in +17 -0
@@ -18,6 +18,23 @@ config BR2_EXTERNAL string option env="BR2_EXTERNAL" +# Hidden config symbols for packages to check system gcc version +config BR2_HOST_GCC_AT_LEAST_4_7 + bool + option env="HOST_GCC_AT_LEAST_4_7" + +config BR2_HOST_GCC_AT_LEAST_4_8 + bool + option env="HOST_GCC_AT_LEAST_4_8" + +config BR2_HOST_GCC_AT_LEAST_4_9 + bool + option env="HOST_GCC_AT_LEAST_4_9" + +config BR2_HOST_GCC_AT_LEAST_5 + bool + option env="HOST_GCC_AT_LEAST_5" + # Hidden boolean selected by packages in need of Java in order to build # (example: xbmc) config BR2_NEEDS_HOST_JAVA
Makefile +1 -0
@@ -712,6 +712,7 @@ COMMON_CONFIG_ENV = \ KCONFIG_TRISTATE=$(BUILD_DIR)/buildroot-config/tristate.config \ BR2_CONFIG=$(BR2_CONFIG) \ BR2_EXTERNAL=$(BR2_EXTERNAL) \ + $(shell support/scripts/gcc-version-variables $(HOSTCC_NOCCACHE)) \ SKIP_LEGACY= xconfig: $(BUILD_DIR)/buildroot-config/qconf outputmakefile
docs/manual/adding-packages-directory.txt +7 -0
@@ -283,6 +283,13 @@ use in the comment. ** Comment string: +gcc >= X.Y+ and/or `gcc <= X.Y` (replace +X.Y+ with the proper version) +* Host GCC version +** Dependency symbol: +BR2_HOST_GCC_AT_LEAST_X_Y+, (replace + +X_Y+ with the proper version, see +Config.in+) +** Comment string: no comment to be added +** Note that it is usually not the package itself that has a minimum + host GCC version, but rather a host-package on which it depends. + * C library ** Dependency symbol: +BR2_TOOLCHAIN_USES_GLIBC+, +BR2_TOOLCHAIN_USES_MUSL+, +BR2_TOOLCHAIN_USES_UCLIBC+
support/scripts/gcc-version-variables new file +56 -0
56 lines not on this page · raw message
Signature · 1 line
2.6.2
PATCH 2/3 Config.in: add symbols for BR2_HOST_GCC_AT_LEAST_X_Y
Arnout, All,
On 2015-11-22 00:18 +0100, Arnout Vandecappelle (Essensium/Mind) spake thusly:
Quoted 3 lines
Some host packages need a recent gcc version. Add symbols to Config.in to specify the HOSTCC version. The values are passed through the environment, and this environment is generated in a new support script.
I really don't like this...
Maybe it is a good candidate for a generated kconfig snippet, instead of this generated-environment oddity?
Anyway, see below, you could generate only one environment variable, instead of all of them...
Quoted 25 lines
Also update the documentation to mention the new symbols.
--- Config.in | 17 ++++++++++ Makefile | 1 + docs/manual/adding-packages-directory.txt | 7 ++++ support/scripts/gcc-version-variables | 56 +++++++++++++++++++++++++++++++ 4 files changed, 81 insertions(+) create mode 100755 support/scripts/gcc-version-variablesConfig.in +6
-0@@ -18,6 +18,23 @@ config BR2_EXTERNAL string option env="BR2_EXTERNAL" +# Hidden config symbols for packages to check system gcc version +config BR2_HOST_GCC_AT_LEAST_4_7 + bool + option env="HOST_GCC_AT_LEAST_4_7" + +config BR2_HOST_GCC_AT_LEAST_4_8
Config.in config BR2_EXTERNAL · line 36
Quoted 10 lines
Config.in +10
-0+ bool + option env="HOST_GCC_AT_LEAST_4_8" + +config BR2_HOST_GCC_AT_LEAST_4_9 + bool + option env="HOST_GCC_AT_LEAST_4_9" + +config BR2_HOST_GCC_AT_LEAST_5 + bool + option env="HOST_GCC_AT_LEAST_5"
If you make each of those options actually select the N-1 option, then all you need if to set one environment variable.
[--SNIP--]
Quoted 5 lines
docs/manual/adding-packages-directory.txt +0
-0
docs/manual/adding-packages-directory.txt use in the comment. · line 291
Quoted 9 lines
docs/manual/adding-packages-directory.txt +6
-0@@ -283,6 +283,13 @@ use in the comment. ** Comment string: +gcc >= X.Y+ and/or `gcc <= X.Y` (replace +X.Y+ with the proper version) +* Host GCC version +** Dependency symbol: +BR2_HOST_GCC_AT_LEAST_X_Y+, (replace + +X_Y+ with the proper version, see +Config.in+) +** Comment string: no comment to be added +** Note that it is usually not the package itself that has a minimum + host GCC version, but rather a host-package on which it depends.
Well, in case the package builds an internal host tool, and properly separates BUILD_CC from CC, then the restriction does apply to the package itself and not a host-package.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 2/3 Config.in: add symbols for BR2_HOST_GCC_AT_LEAST_X_Y
Quoted 8 lines · Yann E. MORIN
Arnout, All,
On 2015-11-22 00:18 +0100, Arnout Vandecappelle (Essensium/Mind) spake thusly:
Quoted 3 lines
Some host packages need a recent gcc version. Add symbols to Config.in to specify the HOSTCC version. The values are passed through the environment, and this environment is generated in a new support script.
I really don't like this...
I originally had it as a make fragment :-P
Quoted 3 lines
Maybe it is a good candidate for a generated kconfig snippet, instead of this generated-environment oddity?
I never thought of that, it would be a possibility. If I would have time :-)
I'd have a go at it.
Quoted 34 lines
Anyway, see below, you could generate only one environment variable, instead of all of them...
Quoted 30 lines
Also update the documentation to mention the new symbols.
--- Config.in | 17 ++++++++++ Makefile | 1 + docs/manual/adding-packages-directory.txt | 7 ++++ support/scripts/gcc-version-variables | 56 +++++++++++++++++++++++++++++++ 4 files changed, 81 insertions(+) create mode 100755 support/scripts/gcc-version-variablesConfig.in +11
-0@@ -18,6 +18,23 @@ config BR2_EXTERNAL string option env="BR2_EXTERNAL" +# Hidden config symbols for packages to check system gcc version +config BR2_HOST_GCC_AT_LEAST_4_7 + bool + option env="HOST_GCC_AT_LEAST_4_7" + +config BR2_HOST_GCC_AT_LEAST_4_8 + bool + option env="HOST_GCC_AT_LEAST_4_8" + +config BR2_HOST_GCC_AT_LEAST_4_9 + bool
Quoted 8 lines
Config.in config BR2_EXTERNAL · line 36
Quoted 5 lines
Config.in +5
-0+ option env="HOST_GCC_AT_LEAST_4_9" + +config BR2_HOST_GCC_AT_LEAST_5 + bool + option env="HOST_GCC_AT_LEAST_5"If you make each of those options actually select the N-1 option, then all you need if to set one environment variable.
Alas, that is not possible with the env option. You'd need two symbols, one for
getting it from the environment and a real one that can be selected.
Quoted 10 lines
[--SNIP--]
Quoted 8 lines
docs/manual/adding-packages-directory.txt +0
-0@@ -283,6 +283,13 @@ use in the comment. ** Comment string: +gcc >= X.Y+ and/or `gcc <= X.Y` (replace +X.Y+ with the proper version)
Quoted 10 lines
docs/manual/adding-packages-directory.txt use in the comment. · line 291
Quoted 6 lines
docs/manual/adding-packages-directory.txt +6
-0+* Host GCC version +** Dependency symbol: +BR2_HOST_GCC_AT_LEAST_X_Y+, (replace + +X_Y+ with the proper version, see +Config.in+) +** Comment string: no comment to be added +** Note that it is usually not the package itself that has a minimum + host GCC version, but rather a host-package on which it depends.Well, in case the package builds an internal host tool, and properly separates
BUILD_CCfrom CC, then the restriction does apply to the package itself and not a host-package.
Yeah I know, however it's complicated to explain that well in the manual, and I
don't believe it will ever happen in practice. Things built with BUILD_CC are usually pretty simple tools.
Regards,
Arnout
Quoted 4 lines
Regards,
Yann E. MORIN.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 2/3 Config.in: add symbols for BR2_HOST_GCC_AT_LEAST_X_Y
Arnout, All,
On 2015-11-29 21:55 +0100, Arnout Vandecappelle spake thusly:
Quoted 10 lines · Yann E. MORIN
Quoted 8 lines
Arnout, All,
On 2015-11-22 00:18 +0100, Arnout Vandecappelle (Essensium/Mind) spake thusly:
Quoted 3 lines
Some host packages need a recent gcc version. Add symbols to Config.in to specify the HOSTCC version. The values are passed through the environment, and this environment is generated in a new support script.
I really don't like this...
Quoted 8 lines
I originally had it as a make fragment :-P
Quoted 3 lines
Maybe it is a good candidate for a generated kconfig snippet, instead of this generated-environment oddity?
I never thought of that, it would be a possibility. If I would have time :-)
I'd have a go at it.
I already have all that is needed to generate a kconfig fragment, in my multi br2-external series.
It was meant only as a mean to add the generated Config.in that aggregates all the br2-external entries, but otherwise adds all the dependencies in the Makefile to ensure the fragment is created before we run any kconfig program.
So, if you could review those patches, we can get them early (if not the complete series) so all you'd have is to write the kconfig snippet generator for the host gcc version checks.
[--SNIP--]
Quoted 20 lines
Quoted 11 lines
Quoted 11 lines
Config.in +11
-0+# Hidden config symbols for packages to check system gcc version +config BR2_HOST_GCC_AT_LEAST_4_7 + bool + option env="HOST_GCC_AT_LEAST_4_7" + +config BR2_HOST_GCC_AT_LEAST_4_8 + bool + option env="HOST_GCC_AT_LEAST_4_8" + +config BR2_HOST_GCC_AT_LEAST_4_9 + boolQuoted 8 lines
Config.in config BR2_EXTERNAL · line 36
Quoted 5 lines
Config.in +5
-0+ option env="HOST_GCC_AT_LEAST_4_9" + +config BR2_HOST_GCC_AT_LEAST_5 + bool + option env="HOST_GCC_AT_LEAST_5"If you make each of those options actually select the N-1 option, then all you need if to set one environment variable.
Quoted 2 lines
Alas, that is not possible with the env option. You'd need two symbols, one for
getting it from the environment and a real one that can be selected.
That's not what I conclude from my experiments:
$ cat env-select.in
comment "What is enabled?"
config FOO
bool
option env="KCFG_FOO"
config BAR
bool
select FOO
option env="KCFG_BAR"
comment "FOO=y"
depends on FOO
comment "BAR=y"
depends on BAR $ KCFG_BAR=y mconf env-select.in
*** What is enabled? ***
*** FOO=y ***
*** BAR=y ***So, it seems BAR does indeed select FOO, no? ;-)
[--SNIP--]
Quoted 11 lines
Quoted 10 lines
docs/manual/adding-packages-directory.txt use in the comment. · line 291
Quoted 6 lines
docs/manual/adding-packages-directory.txt +6
-0+* Host GCC version +** Dependency symbol: +BR2_HOST_GCC_AT_LEAST_X_Y+, (replace + +X_Y+ with the proper version, see +Config.in+) +** Comment string: no comment to be added +** Note that it is usually not the package itself that has a minimum + host GCC version, but rather a host-package on which it depends.Well, in case the package builds an internal host tool, and properly separates
BUILD_CCfrom CC, then the restriction does apply to the package itself and not a host-package.
Quoted 3 lines
Yeah I know, however it's complicated to explain that well in the manual, and I
don't believe it will ever happen in practice. Things built withBUILD_CCare usually pretty simple tools.
Agreed.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 2/3 Config.in: add symbols for BR2_HOST_GCC_AT_LEAST_X_Y
Quoted 26 lines · Yann E. MORIN
Arnout, All,
On 2015-11-29 21:55 +0100, Arnout Vandecappelle spake thusly:
Quoted 10 lines · Yann E. MORIN
Quoted 8 lines
Arnout, All,
On 2015-11-22 00:18 +0100, Arnout Vandecappelle (Essensium/Mind) spake thusly:
Quoted 3 lines
Some host packages need a recent gcc version. Add symbols to Config.in to specify the HOSTCC version. The values are passed through the environment, and this environment is generated in a new support script.
I really don't like this...
Quoted 8 lines
I originally had it as a make fragment :-P
Quoted 3 lines
Maybe it is a good candidate for a generated kconfig snippet, instead of this generated-environment oddity?
I never thought of that, it would be a possibility. If I would have time :-)
I'd have a go at it.I already have all that is needed to generate a kconfig fragment, in my multi br2-external series.
Quoted 8 lines
It was meant only as a mean to add the generated Config.in that aggregates all the br2-external entries, but otherwise adds all the dependencies in the
Makefileto ensure the fragment is created before we run any kconfig program.So, if you could review those patches, we can get them early (if not the complete series) so all you'd have is to write the kconfig snippet generator for the host gcc version checks.
I'll try to do that.
Quoted 41 lines
[--SNIP--]
Quoted 20 lines
Quoted 11 lines
Quoted 11 lines
Config.in +11
-0+# Hidden config symbols for packages to check system gcc version +config BR2_HOST_GCC_AT_LEAST_4_7 + bool + option env="HOST_GCC_AT_LEAST_4_7" + +config BR2_HOST_GCC_AT_LEAST_4_8 + bool + option env="HOST_GCC_AT_LEAST_4_8" + +config BR2_HOST_GCC_AT_LEAST_4_9 + boolQuoted 8 lines
Config.in config BR2_EXTERNAL · line 36
Quoted 5 lines
Config.in +5
-0+ option env="HOST_GCC_AT_LEAST_4_9" + +config BR2_HOST_GCC_AT_LEAST_5 + bool + option env="HOST_GCC_AT_LEAST_5"If you make each of those options actually select the N-1 option, then all you need if to set one environment variable.
Quoted 2 lines
Alas, that is not possible with the env option. You'd need two symbols, one for
getting it from the environment and a real one that can be selected.That's not what I conclude from my experiments:
$ cat env-select.in comment "What is enabled?" config FOO bool option env="KCFG_FOO" config BAR bool select FOO option env="KCFG_BAR" comment "FOO=y" depends on FOO comment "BAR=y" depends on BAR
Quoted 6 lines
$ KCFG_BAR=y mconf env-select.in *** What is enabled? *** *** FOO=y *** *** BAR=y ***So, it seems BAR does indeed select FOO, no? ;-)
OK, I just remembered something like that from experiments with LEGACY and
didn't try again. I guess I remembered incorrectly :-)
Regards,
Arnout
Quoted 22 lines
[--SNIP--]
Quoted 11 lines
Quoted 10 lines
docs/manual/adding-packages-directory.txt use in the comment. · line 291
Quoted 6 lines
docs/manual/adding-packages-directory.txt +6
-0+* Host GCC version +** Dependency symbol: +BR2_HOST_GCC_AT_LEAST_X_Y+, (replace + +X_Y+ with the proper version, see +Config.in+) +** Comment string: no comment to be added +** Note that it is usually not the package itself that has a minimum + host GCC version, but rather a host-package on which it depends.Well, in case the package builds an internal host tool, and properly separates
BUILD_CCfrom CC, then the restriction does apply to the package itself and not a host-package.Quoted 3 lines
Yeah I know, however it's complicated to explain that well in the manual, and I
don't believe it will ever happen in practice. Things built withBUILD_CCare usually pretty simple tools.Agreed.
Regards,
Yann E. MORIN.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 2/3 Config.in: add symbols for BR2_HOST_GCC_AT_LEAST_X_Y
Arnout, All,
On 2015-11-29 22:41 +0100, Arnout Vandecappelle spake thusly:
Quoted 3 lines · Yann E. MORIN
Quoted 2 lines
On 2015-11-29 21:55 +0100, Arnout Vandecappelle spake thusly:
Quoted 1 line · Yann E. MORIN
[--SNIP--]
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
If you make each of those options actually select the N-1 option, then all you need if to set one environment variable.
Alas, that is not possible with the env option. You'd need two symbols, one for
getting it from the environment and a real one that can be selected.That's not what I conclude from my experiments:
[--SNIP--]
Quoted 2 lines
OK, I just remembered something like that from experiments with LEGACY and
didn't try again. I guess I remembered incorrectly :-)
What is sure is that those symbols are not saved in .config .
Not sure how legacy would have been impacted by the env option, though...
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 3/3 nodejs: version 4.X needs host GCC >= 4.8
In reply to Arnout Vandecappelle (Essensium/Mind)Fixes
http://autobuild.buildroot.net/results/3fd1d18f0535bb8b969f808a5837c4a8111e69b9
http://autobuild.buildroot.org/results/72b80a434547931e1deb6f0ba793a6d68accc9a2
--- package/nodejs/Config.in | 2 ++ 1 file changed, 2 insertions(+)
package/nodejs/Config.in +2 -0
@@ -51,10 +51,12 @@ config BR2_BR2_PACKAGE_NODEJS_0_12_X config BR2_BR2_PACKAGE_NODEJS_4_X bool "v4.1.2" depends on BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS + depends on BR2_HOST_GCC_AT_LEAST_4_8 depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 comment "v4.1.2 needs a toolchain w/ gcc >= 4.8" depends on BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS + depends on BR2_HOST_GCC_AT_LEAST_4_8 depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 endchoice
Signature · 1 line
2.6.2
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
In reply to Arnout Vandecappelle (Essensium/Mind)Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle (Essensium/Mind) <[email protected]> writes:
HOSTCC_VERSIONis no longer used since gcc switched to the package infrastructure ine236fe481. It was in fact no longer needed since we dropped support for gcc 4.3.---
Note that we currently claim to support system gcc >= 2.95, but I don't think that matches reality...
Ehh, no. I guess a 4.x version would make more sense. Any idea what 'x' should be? 3? 5? 7?
Committed to next, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
Quoted 6 lines · Peter Korsgaard
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle (Essensium/Mind) <[email protected]> writes:
HOSTCC_VERSIONis no longer used since gcc switched to the package infrastructure ine236fe481. It was in fact no longer needed since we dropped support for gcc 4.3.
Quoted 7 lines
Quoted 4 lines
---
Note that we currently claim to support system gcc >= 2.95, but I don't think that matches reality...Ehh, no. I guess a 4.x version would make more sense. Any idea what 'x' should be? 3? 5? 7?
We'd need to check all the host packages (plus the packages that build a host tool as part of the target build, like uboot) to be sure of that. The autobuilders tell us that 4.7 at least is OK.
Regards,
Arnout
Quoted 3 lines
Committed to next, thanks.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
Arnout,
Quoted 6 lines · Arnout Vandecappelle
Quoted 2 lines
Ehh, no. I guess a 4.x version would make more sense. Any idea what 'x' should be? 3? 5? 7?
We'd need to check all the host packages (plus the packages that build a host tool as part of the target build, like uboot) to be sure of that. The autobuilders tell us that 4.7 at least is OK.
My autobuilder instance uses gcc 4.4:
test at build:~$ gcc -v
[...]
gcc version 4.4.5 (Debian 4.4.5-8)
(Yes, I'm running old stuff. On purpose.)
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Ehh, no. I guess a 4.x version would make more sense. Any idea what 'x' should be? 3? 5? 7?
We'd need to check all the host packages (plus the packages that build a host tool as part of the target build, like uboot) to be sure of that. The autobuilders tell us that 4.7 at least is OK.
Quoted 7 lines
My autobuilder instance uses gcc 4.4:
test at build:~$ gcc -v
[...]
gcc version 4.4.5 (Debian 4.4.5-8)(Yes, I'm running old stuff. On purpose.)
Ok, good. RHEL6 afaik also uses GCC 4.4. In lack of a better option I suggest we start requiring >= 4.4.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
In reply to Thomas PetazzoniQuoted 11 lines · Thomas Petazzoni
Arnout,
Quoted 6 lines · Arnout Vandecappelle
Quoted 2 lines
Ehh, no. I guess a 4.x version would make more sense. Any idea what 'x' should be? 3? 5? 7?
We'd need to check all the host packages (plus the packages that build a host tool as part of the target build, like uboot) to be sure of that. The autobuilders tell us that 4.7 at least is OK.
Quoted 7 lines
My autobuilder instance uses gcc 4.4:
test at build:~$ gcc -v
[...]
gcc version 4.4.5 (Debian 4.4.5-8)(Yes, I'm running old stuff. On purpose.)
So, should we set it to 4.4?
Ideally we should have a test instance on RHEL5 as well, there are definitely
still company deployments based on that. RHEL5 has gcc 4.1.
RHEL4 has gcc 3.4 but I don't think that that is very useful.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/3 package/Makefile.in: remove HOSTCC_VERSION
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Quoted 5 lines
Quoted 3 lines
gcc version 4.4.5 (Debian 4.4.5-8)
(Yes, I'm running old stuff. On purpose.)
So, should we set it to 4.4?
I think so, yes. With the autobuilder running we're fairly confident that it really works with such an old gcc.
Quoted 2 lines
Ideally we should have a test instance on RHEL5 as well, there are definitely
still company deployments based on that. RHEL5 has gcc 4.1.
I agree that we should have an autobuilder instance running with our minimum hostcc version we support, as these kind of things can very easily break without us noticing.
With that said, I really question the sensibility of building modern packages on a 10 year old host system (gcc 4.1.0 is from February 2006), and I would guess quite some stuff is broken.
And if something important is (or becomes in the future) broken, do we spend time on fixing it? What if upstream doesn't care about ancient systems?
Quoted 1 line
RHEL4 has gcc 3.4 but I don't think that that is very useful.
No, please not.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard