[dpdk-dev,v2] mk: Rework gcc version detection to permit versions newer than 4.x

Message ID e2043c84f5643ec1c1bb09d9f695c214df6e9966.1424703222.git.pmatilai@redhat.com (mailing list archive)
State Accepted, archived
Headers

Commit Message

Panu Matilainen Feb. 23, 2015, 2:53 p.m. UTC
  Separately comparing major and minor versions becomes seriously clumsy
when with major version changes, convert the entire version string into
a numeric value (ie 4.6.0 becomes 460 and 5.0.0 becomes 500) and use
that for comparisons, eliminate unnecessary negations while at it.
This makes the comparisons simpler, more obvious and makes gcc 5.0
naturally recognized at least as capable as newest 4.x.

This three-digit scheme would run into trouble if gcc ever went to
two-digit version segments, but that hasn't happened in the last 10+
years so it seems like a safe assumption.

Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
 lib/librte_pmd_fm10k/Makefile            |  2 +-
 lib/librte_pmd_i40e/Makefile             |  2 +-
 lib/librte_pmd_ixgbe/Makefile            |  6 +++---
 lib/librte_pmd_vmxnet3/Makefile          |  2 +-
 mk/toolchain/gcc/rte.toolchain-compat.mk | 22 ++++++++++------------
 5 files changed, 16 insertions(+), 18 deletions(-)
  

Comments

Thomas Monjalon Feb. 24, 2015, 2:46 a.m. UTC | #1
> Separately comparing major and minor versions becomes seriously clumsy
> when with major version changes, convert the entire version string into
> a numeric value (ie 4.6.0 becomes 460 and 5.0.0 becomes 500) and use
> that for comparisons, eliminate unnecessary negations while at it.
> This makes the comparisons simpler, more obvious and makes gcc 5.0
> naturally recognized at least as capable as newest 4.x.
> 
> This three-digit scheme would run into trouble if gcc ever went to
> two-digit version segments, but that hasn't happened in the last 10+
> years so it seems like a safe assumption.
> 
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>

Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>

Applied, thanks
  
David Marchand Feb. 24, 2015, 9:25 a.m. UTC | #2
Hello Panu,

Looks like there is an issue with gcc 4.7 on my debian.

$ make config T=x86_64-native-linuxapp-gcc && make -j8
../mk/toolchain/gcc/rte.toolchain-compat.mk:46: You are using GCC < 4.x.
This is neither supported, nor tested.
../mk/toolchain/gcc/rte.toolchain-compat.mk:46: You are using GCC < 4.x.
This is neither supported, nor tested.

$ gcc -dumpversion
4.7

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
  
Panu Matilainen Feb. 24, 2015, 9:50 a.m. UTC | #3
On 02/24/2015 11:25 AM, David Marchand wrote:
> Hello Panu,
>
> Looks like there is an issue with gcc 4.7 on my debian.
>
> $ make config T=x86_64-native-linuxapp-gcc && make -j8
> ../mk/toolchain/gcc/rte.toolchain-compat.mk:46
> <http://rte.toolchain-compat.mk:46>: You are using GCC < 4.x. This is
> neither supported, nor tested.
> ../mk/toolchain/gcc/rte.toolchain-compat.mk:46
> <http://rte.toolchain-compat.mk:46>: You are using GCC < 4.x. This is
> neither supported, nor tested.
>
> $ gcc -dumpversion
> 4.7

Meh. This seems to be a Debian specific modification to gcc, discussed 
here and there including but not limited to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759038
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404

Dunno about Ubuntu, but at least Ubuntu already changed it back. But I 
guess there's no choice but to work around it anyway... Easiest solution 
is probably just to drop the micro version out, back to the granularity 
where it used to be.

	- Panu -
  
David Marchand Feb. 24, 2015, 10:09 a.m. UTC | #4
On Tue, Feb 24, 2015 at 10:50 AM, Panu Matilainen <pmatilai@redhat.com>
wrote:

> On 02/24/2015 11:25 AM, David Marchand wrote:
>
>> Hello Panu,
>>
>> Looks like there is an issue with gcc 4.7 on my debian.
>>
>> $ make config T=x86_64-native-linuxapp-gcc && make -j8
>> ../mk/toolchain/gcc/rte.toolchain-compat.mk:46
>> <http://rte.toolchain-compat.mk:46>: You are using GCC < 4.x. This is
>> neither supported, nor tested.
>> ../mk/toolchain/gcc/rte.toolchain-compat.mk:46
>> <http://rte.toolchain-compat.mk:46>: You are using GCC < 4.x. This is
>> neither supported, nor tested.
>>
>> $ gcc -dumpversion
>> 4.7
>>
>
> Meh. This seems to be a Debian specific modification to gcc, discussed
> here and there including but not limited to:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759038
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404
>
> Dunno about Ubuntu, but at least Ubuntu already changed it back. But I
> guess there's no choice but to work around it anyway... Easiest solution is
> probably just to drop the micro version out, back to the granularity where
> it used to be.


Yes, I suppose so, but then we are almost at square one :-)
  
David Marchand Feb. 24, 2015, 10:21 a.m. UTC | #5
On Tue, Feb 24, 2015 at 11:09 AM, David Marchand <david.marchand@6wind.com>
wrote:

> On Tue, Feb 24, 2015 at 10:50 AM, Panu Matilainen <pmatilai@redhat.com>
> wrote:
>
>> $ gcc -dumpversion
>>> 4.7
>>>
>>
>> Meh. This seems to be a Debian specific modification to gcc, discussed
>> here and there including but not limited to:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759038
>> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404
>>
>> Dunno about Ubuntu, but at least Ubuntu already changed it back. But I
>> guess there's no choice but to work around it anyway... Easiest solution is
>> probably just to drop the micro version out, back to the granularity where
>> it used to be.
>
>
> Yes, I suppose so, but then we are almost at square one :-)
>
>
Hum, how about something like always appending .0.0 to the gcc -dumpversion
then cut at 3 characters ?
  
Panu Matilainen Feb. 24, 2015, 10:21 a.m. UTC | #6
On 02/24/2015 12:09 PM, David Marchand wrote:
> On Tue, Feb 24, 2015 at 10:50 AM, Panu Matilainen <pmatilai@redhat.com
> <mailto:pmatilai@redhat.com>> wrote:
>
>     On 02/24/2015 11:25 AM, David Marchand wrote:
>
>         Hello Panu,
>
>         Looks like there is an issue with gcc 4.7 on my debian.
>
>         $ make config T=x86_64-native-linuxapp-gcc && make -j8
>         ../mk/toolchain/gcc/rte.__toolchain-compat.mk:46
>         <http://rte.toolchain-compat.mk:46>
>         <http://rte.toolchain-compat.__mk:46
>         <http://rte.toolchain-compat.mk:46>>: You are using GCC < 4.x.
>         This is
>         neither supported, nor tested.
>         ../mk/toolchain/gcc/rte.__toolchain-compat.mk:46
>         <http://rte.toolchain-compat.mk:46>
>         <http://rte.toolchain-compat.__mk:46
>         <http://rte.toolchain-compat.mk:46>>: You are using GCC < 4.x.
>         This is
>         neither supported, nor tested.
>
>         $ gcc -dumpversion
>         4.7
>
>
>     Meh. This seems to be a Debian specific modification to gcc,
>     discussed here and there including but not limited to:
>     https://bugs.debian.org/cgi-__bin/bugreport.cgi?bug=759038
>     <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759038>
>     https://bugs.launchpad.net/__ubuntu/+source/gcc-4.8/+bug/__1360404
>     <https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404>
>
>     Dunno about Ubuntu, but at least Ubuntu already changed it back. But
>     I guess there's no choice but to work around it anyway... Easiest
>     solution is probably just to drop the micro version out, back to the
>     granularity where it used to be.
>
>
> Yes, I suppose so, but then we are almost at square one :-)

Not really, the big deal about the change was to compare the version as 
a regular number instead of segmented comparison. Bringing in the 
micro-version was more of a side-effect than anything else, it just 
seemed simpler than having to cut out major.minor specifically.

So no big loss, just mildly annoying workaround for upstream deviation :)

	- Panu -
  
John McNamara Feb. 24, 2015, 10:36 a.m. UTC | #7
> -----Original Message-----

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Marchand

> Sent: Tuesday, February 24, 2015 10:21 AM

> To: Panu Matilainen

> Cc: dev@dpdk.org

> Subject: Re: [dpdk-dev] [PATCH v2] mk: Rework gcc version detection to

> permit versions newer than 4.x

> 

> On Tue, Feb 24, 2015 at 11:09 AM, David Marchand

> <david.marchand@6wind.com>

> wrote:

> 

> > On Tue, Feb 24, 2015 at 10:50 AM, Panu Matilainen

> > <pmatilai@redhat.com>

> > wrote:

> >

> >> $ gcc -dumpversion

> >>> 4.7

> >>>

> Hum, how about something like always appending .0.0 to the gcc -

> dumpversion then cut at 3 characters ?


Hi,

Or something like this in Sed or Perl within the $(shell) expansion:


    $ gcc -dumpversion | perl -pe 's/^(\d+\.\d+)$/$1.0/'
    4.7.0

    # Tests:
    $ echo 4.7 | perl -pe 's/^(\d+\.\d+)$/$1.0/'
    4.7.0

    $ echo 4.7.0 | perl -pe 's/^(\d+\.\d+)$/$1.0/'
    4.7.0

    $ echo 4.7.1 | perl -pe 's/^(\d+\.\d+)$/$1.0/' 
    4.7.1

    $ echo 144.7 | perl -pe 's/^(\d+\.\d+)$/$1.0/'  
    144.7.0


John
--
  
David Marchand Feb. 24, 2015, 10:44 a.m. UTC | #8
On Tue, Feb 24, 2015 at 11:36 AM, Mcnamara, John <john.mcnamara@intel.com>
wrote:

>
> > >> $ gcc -dumpversion
> > >>> 4.7
> > >>>
> > Hum, how about something like always appending .0.0 to the gcc -
> > dumpversion then cut at 3 characters ?
>
> Hi,
>
> Or something like this in Sed or Perl within the $(shell) expansion:
>

Well, we have no dependency on perl so far.
I would prefer we keep at just makefile and shell stuff.

Olivier ? opinion ?
  
Bruce Richardson Feb. 24, 2015, 10:50 a.m. UTC | #9
On Tue, Feb 24, 2015 at 11:44:21AM +0100, David Marchand wrote:
> On Tue, Feb 24, 2015 at 11:36 AM, Mcnamara, John <john.mcnamara@intel.com>
> wrote:
> 
> >
> > > >> $ gcc -dumpversion
> > > >>> 4.7
> > > >>>
> > > Hum, how about something like always appending .0.0 to the gcc -
> > > dumpversion then cut at 3 characters ?
> >
> > Hi,
> >
> > Or something like this in Sed or Perl within the $(shell) expansion:
> >
> 
> Well, we have no dependency on perl so far.
> I would prefer we keep at just makefile and shell stuff.
> 
> Olivier ? opinion ?
> 
> 
> -- 
> David Marchand

I think the suggestion of just appending .0.0 is the simplest option which
should also work well.

Regards,

/Bruce
  
Panu Matilainen Feb. 24, 2015, 10:53 a.m. UTC | #10
On 02/24/2015 12:44 PM, David Marchand wrote:
> On Tue, Feb 24, 2015 at 11:36 AM, Mcnamara, John
> <john.mcnamara@intel.com <mailto:john.mcnamara@intel.com>> wrote:
>
>
>     > >> $ gcc -dumpversion
>     > >>> 4.7
>     > >>>
>     > Hum, how about something like always appending .0.0 to the gcc -
>     > dumpversion then cut at 3 characters ?
>
>     Hi,
>
>     Or something like this in Sed or Perl within the $(shell) expansion:
>
>
> Well, we have no dependency on perl so far.
> I would prefer we keep at just makefile and shell stuff.
 >
 > Olivier ? opinion ?
 >

No need or sense to bring in the perl monster for something this silly.
Already sent a patch and you were supposed to be cc'd but somehow that 
part went to bitbucket:
http://dpdk.org/ml/archives/dev/2015-February/014051.html

	- Panu -
  
John McNamara Feb. 24, 2015, 10:58 a.m. UTC | #11
> From: David Marchand [mailto:david.marchand@6wind.com] 

> Sent: Tuesday, February 24, 2015 10:44 AM

> To: Mcnamara, John

> Cc: Panu Matilainen; dev@dpdk.org; Olivier Matz

> Subject: Re: [dpdk-dev] [PATCH v2] mk: Rework gcc version detection to permit versions newer than 4.x

> 

>> Or something like this in Sed or Perl within the $(shell) expansion:

> 

> Well, we have no dependency on perl so far.

> I would prefer we keep at just makefile and shell stuff.

> 

> Olivier ? opinion ?


Hi,

A similar anchored regex would work in sed:
    
    $ echo 4.7     | sed -r 's/^[0-9]+\.[0-9]$/&.0/'
    4.7.0

    $ echo 4.7.2   | sed -r 's/^[0-9]+\.[0-9]$/&.0/'
    4.7.2

    $ echo 144.7.2 | sed -r 's/^[0-9]+\.[0-9]$/&.0/' 
    144.7.2

John
--
  

Patch

diff --git a/lib/librte_pmd_fm10k/Makefile b/lib/librte_pmd_fm10k/Makefile
index 986f4ef..2902d64 100644
--- a/lib/librte_pmd_fm10k/Makefile
+++ b/lib/librte_pmd_fm10k/Makefile
@@ -62,7 +62,7 @@  else
 #
 # CFLAGS for gcc
 #
-ifneq ($(shell test $(GCC_MAJOR_VERSION) -le 4 -a $(GCC_MINOR_VERSION) -le 3 && echo 1), 1)
+ifeq ($(shell test $(GCC_VERSION) -ge 440 && echo 1), 1)
 CFLAGS     += -Wno-deprecated
 endif
 CFLAGS_BASE_DRIVER = -Wno-unused-parameter -Wno-unused-value
diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile
index 9a0eec8..484379a 100644
--- a/lib/librte_pmd_i40e/Makefile
+++ b/lib/librte_pmd_i40e/Makefile
@@ -69,7 +69,7 @@  CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast
 CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
 CFLAGS_BASE_DRIVER += -Wno-format-security
 
-ifeq ($(shell test $(GCC_MAJOR_VERSION) -ge 4 -a $(GCC_MINOR_VERSION) -ge 4 && echo 1), 1)
+ifeq ($(shell test $(GCC_VERSION) -ge 440 && echo 1), 1)
 CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
 endif
 
diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile
index 0279f8c..ab56cbf 100644
--- a/lib/librte_pmd_ixgbe/Makefile
+++ b/lib/librte_pmd_ixgbe/Makefile
@@ -60,18 +60,18 @@  else
 #
 # CFLAGS for gcc
 #
-ifneq ($(shell test $(GCC_MAJOR_VERSION) -le 4 -a $(GCC_MINOR_VERSION) -le 3 && echo 1), 1)
+ifeq ($(shell test $(GCC_VERSION) -ge 440 && echo 1), 1)
 CFLAGS     += -Wno-deprecated
 endif
 CFLAGS_BASE_DRIVER = -Wno-unused-parameter -Wno-unused-value
 CFLAGS_BASE_DRIVER += -Wno-strict-aliasing -Wno-format-extra-args
 
-ifeq ($(shell test $(GCC_MAJOR_VERSION) -ge 4 -a $(GCC_MINOR_VERSION) -ge 6 && echo 1), 1)
+ifeq ($(shell test $(GCC_VERSION) -ge 460 && echo 1), 1)
 CFLAGS_ixgbe_common.o += -Wno-unused-but-set-variable
 CFLAGS_ixgbe_x550.o += -Wno-unused-but-set-variable -Wno-maybe-uninitialized
 endif
 
-ifeq ($(shell test $(GCC_MAJOR_VERSION) -le 4 -a $(GCC_MINOR_VERSION) -le 6 && echo 1), 1)
+ifeq ($(shell test $(GCC_VERSION) -le 460 && echo 1), 1)
 CFLAGS_ixgbe_x550.o += -Wno-uninitialized
 CFLAGS_ixgbe_phy.o += -Wno-uninitialized
 endif
diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile
index 93e5580..9dda0a7 100644
--- a/lib/librte_pmd_vmxnet3/Makefile
+++ b/lib/librte_pmd_vmxnet3/Makefile
@@ -56,7 +56,7 @@  else
 #
 # CFLAGS for gcc
 #
-ifneq ($(shell test $(GCC_MAJOR_VERSION) -le 4 -a $(GCC_MINOR_VERSION) -le 3 && echo 1), 1)
+ifeq ($(shell test $(GCC_VERSION) -ge 440 && echo 1), 1)
 CFLAGS     += -Wno-deprecated
 endif
 CFLAGS_BASE_DRIVER = -Wno-unused-parameter -Wno-unused-value
diff --git a/mk/toolchain/gcc/rte.toolchain-compat.mk b/mk/toolchain/gcc/rte.toolchain-compat.mk
index e40e103..a867559 100644
--- a/mk/toolchain/gcc/rte.toolchain-compat.mk
+++ b/mk/toolchain/gcc/rte.toolchain-compat.mk
@@ -38,17 +38,15 @@ 
 
 #find out GCC version
 
-GCC_MAJOR_VERSION = $(shell $(CC) -dumpversion | cut -f1 -d.)
+GCC_VERSION = $(subst .,,$(shell $(CC) -dumpversion))
 
-# if GCC is not 4.x
-ifneq ($(GCC_MAJOR_VERSION),4)
+# if GCC is older than 4.x
+ifeq ($(shell test $(GCC_VERSION) -lt 400 && echo 1), 1)
 	MACHINE_CFLAGS =
-$(warning You are not using GCC 4.x. This is neither supported, nor tested.)
+$(warning You are using GCC < 4.x. This is neither supported, nor tested.)
 
 
 else
-	GCC_MINOR_VERSION = $(shell $(CC) -dumpversion | cut -f2 -d.)
-
 # GCC graceful degradation
 # GCC 4.2.x - added support for generic target
 # GCC 4.3.x - added support for core2, ssse3, sse4.1, sse4.2
@@ -57,18 +55,18 @@  else
 # GCC 4.6.x - added support for corei7, corei7-avx
 # GCC 4.7.x - added support for fsgsbase, rdrnd, f16c, core-avx-i, core-avx2
 
-	ifeq ($(shell test $(GCC_MINOR_VERSION) -le 7 && echo 1), 1)
+	ifeq ($(shell test $(GCC_VERSION) -le 470 && echo 1), 1)
 		MACHINE_CFLAGS := $(patsubst -march=core-avx-i,-march=corei7-avx,$(MACHINE_CFLAGS))
 		MACHINE_CFLAGS := $(patsubst -march=core-avx2,-march=core-avx2,$(MACHINE_CFLAGS))
 	endif
-	ifeq ($(shell test $(GCC_MINOR_VERSION) -lt 6 && echo 1), 1)
+	ifeq ($(shell test $(GCC_VERSION) -lt 460 && echo 1), 1)
 		MACHINE_CFLAGS := $(patsubst -march=corei7-avx,-march=core2 -maes -mpclmul -mavx,$(MACHINE_CFLAGS))
 		MACHINE_CFLAGS := $(patsubst -march=corei7,-march=core2 -maes -mpclmul,$(MACHINE_CFLAGS))
 	endif
-	ifeq ($(shell test $(GCC_MINOR_VERSION) -lt 5 && echo 1), 1)
+	ifeq ($(shell test $(GCC_VERSION) -lt 450 && echo 1), 1)
 		MACHINE_CFLAGS := $(patsubst -march=atom,-march=core2 -mssse3,$(MACHINE_CFLAGS))
 	endif
-	ifeq ($(shell test $(GCC_MINOR_VERSION) -lt 4 && echo 1), 1)
+	ifeq ($(shell test $(GCC_VERSION) -lt 440 && echo 1), 1)
 		MACHINE_CFLAGS := $(filter-out -mavx -mpclmul -maes,$(MACHINE_CFLAGS))
 		ifneq ($(findstring SSE4_2, $(CPUFLAGS)),)
 			MACHINE_CFLAGS += -msse4.2
@@ -77,12 +75,12 @@  else
 			MACHINE_CFLAGS += -msse4.1
 		endif
 	endif
-	ifeq ($(shell test $(GCC_MINOR_VERSION) -lt 3 && echo 1), 1)
+	ifeq ($(shell test $(GCC_VERSION) -lt 430 && echo 1), 1)
 		MACHINE_CFLAGS := $(filter-out -msse% -mssse%,$(MACHINE_CFLAGS))
 		MACHINE_CFLAGS := $(patsubst -march=core2,-march=generic,$(MACHINE_CFLAGS))
 		MACHINE_CFLAGS += -msse3
 	endif
-	ifeq ($(shell test $(GCC_MINOR_VERSION) -lt 2 && echo 1), 1)
+	ifeq ($(shell test $(GCC_VERSION) -lt 420 && echo 1), 1)
 		MACHINE_CFLAGS := $(filter-out -march% -mtune% -msse%,$(MACHINE_CFLAGS))
 	endif
 endif