Better gcc compiler version check. Previous check failed for gcc-10

[atupone]

No description provided.

[jwmelto]

Can you please describe the motivation for this change?

A couple of comments about your approach:

• the $(...) syntax is specific to bash or zsh (maybe ksh, I forget). Specifically, it is not supported by sh. This is confused by the fact that sh may actually be a link to a newer shell on some systems. Unless this is explicitly a bash script, this change may not work on some platforms.
• regexes are powerful but hard to grok. It’s clear from your expected values what you think it should do but less clear how or that it does it. What value does this change provide over what is there? Why is it better?
• gcc has adopted the modern philosophy of rapidly increasing major numbers. I think 10 may be available. How will this logic support 2-digit major versions?
• what I expected was a numerical comparison rather than a lexical one. That seems more robust and easier to comprehend. Did you consider that, and if so, what were your reasons for rejecting it?

[atupone]

Can you please describe the motivation for this change?
Previous check was "10.1.0" >= "4.3" and it did not succeed.
the only comparison could be made as string as 10.1.0 is not a number
the change is to make each version pieces as a 2 digit number and concatenate all
so 10.1.0 become 100100
and 8.3.1 become 080101
and also 4.3 to become 040300

I understand that some older gcc version gave us only two version pieces: major.minor

[jwmelto]

This doesn't work for MacOS 10.13 (should it? does it need to?

Goliath:~ jwmelto$ gcc -dumpversion | sed -e 's|\.\([[0-9]][[0-9]]\)|\1|g' -e 's|\.\([[0-9]]\)|0\1|g' -e 's|^[[0-9]]\{3,4\}$|&00|'
4.2.1

Suggested change

	GCCVER=`$CC -dumpversion | sed -e 's|\.\([[0-9]][[0-9]]\)|\1|g' -e 's|\.\([[0-9]]\)|0\1|g' -e 's|^[[0-9]]\{3,4\}$|&00|'`
	GCCVER=`$CC -dumpversion | awk -F. '{printf "%02d%02d%02d", $1,$2,$3}'`

or use ax_compare_version as @blast007 suggested

[jwmelto]

That looks familiar. Good change.

[jwmelto]

Now I know why this looks familiar. See #236