[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.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
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(-)

On 22-11-15 00:18, Arnout Vandecappelle (Essensium/Mind) wrote:
> 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.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

 I just now notice that this patch is not really for master but for next, while
the other two are for master...


 Regards,
 Arnout

> ---
> 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(-)
> 
> diff --git a/package/Makefile.in b/package/Makefile.in
> index 85008bb..82a66c2 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -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
>

>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:

 > 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.

 > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
 > ---
 > 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.

On 22-11-15 22:43, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:
>
>  > 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.
>
>  > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>  > ---
>  > 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

>
> Committed to next, thanks.
>

Arnout,

On Mon, 23 Nov 2015 20:50:36 +0100, Arnout Vandecappelle wrote:

> > 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@build:~$ gcc -v
[...]
gcc version 4.4.5 (Debian 4.4.5-8)

(Yes, I'm running old stuff. On purpose.)

Thomas

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

>> > 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@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.

On 29-11-15 18:52, Thomas Petazzoni wrote:
> Arnout,
> 
> On Mon, 23 Nov 2015 20:50:36 +0100, Arnout Vandecappelle wrote:
> 
>>> 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@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

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> 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.


 >  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?


 >  RHEL4 has gcc 3.4 but I don't think that that is very useful.

No, please not.