valgrind: doesn't build with an old clang

[mojca (Mojca Miklavec)]

valgrind fails to build already at configure time if clang from xcode 425 is used, complaining about too old compiler:

checking for a supported version of gcc... no (applellvm-4.2)
configure: error: please use gcc >= 3.0 or clang >= 2.9 or icc >= 13.0

A naive addition to the Portfile that blacklisted /usr/bin/clang++ (and llvm-gcc-4.2 just in case) made the build succeed:

PortGroup           compiler_blacklist_versions 1.0
compiler.blacklist  *gcc* {clang < 500}

but I didn't test macports-clang-3.3, llvm-gcc-4.2 or xcode 5. I'm also not sure whether the port needs some special handling about gcc (I don't understand what the rest of the portfile does).

It is also possible that the configure script simply fails to realize that clang++ is in fact some flavour of clang 3.2 (based on LLVM 3.2svn) that might work if the configure check was fixed.

I can do more tests if needed.

[raimue (Rainer Müller)]

This is probably the same issue as described in #32994 and #49161, which I assumed was fixed. The configure script wants to exclude gcc < 3.0, but the --version output (and also the version numbering!) of Apple clang is different from mainline clang. Therefore the script does not recognize this is actually clang and assumes it must be an old gcc.

This issue was supposed to be fixed with this commit:

$ svn log -c14624 svn://svn.valgrind.org/valgrind
------------------------------------------------------------------------
r14624 | sewardj | 2014-10-13 15:03:50 +0200 (Mon, 13 Oct 2014) | 6 lines

Modify the compiler detection test so as to accept "Apple LLVM version
5.1" (etc) and identify it as a Clang variant.  Without that, it gets
misidentified as a gcc variant, which causes problems with Makefile.am's
that use the derived COMPILER_IS_CLANG conditional.


------------------------------------------------------------------------

I can only guess that one of the $CC --version | $SED ... expressions does not match as expected (maybe some syntax issue with /usr/bin/sed vs. gsed, although it looks portable?). Could you please run configure with the following change and attach the resulting main.log?

devel/valgrind/Portfile

@@ -27 +27 @@
 # Ignore trace reports about boost, Qt and OpenMP
 # as they are only used for tests
 
+configure.cmd       sh -x ./configure
 configure.args      --without-mpicc
 
 if {${build_arch} eq "i386"} {

[mojca (Mojca Miklavec)]

Oh, wait. It was me who opened the ticket #49161 that was closed with "I believe this has been fixed upstream." I'm sorry, I checked the tickets, but I only checked for open ones.

I'm not sure what your suggestion was about sh -x ./configure, but anyway, here's my analysis of configure.ac:

> /usr/bin/clang  --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

> /usr/bin/clang  --version | sed -n -e 's/.*\Apple \(LLVM\) version.*clang.*/\1/p'
LLVM

So the first test is true and we get

is_clang="applellvm"

and

> /usr/bin/clang --version | sed -n -e 's/.*LLVM version \([0-9.]*\).*$/\1/p'
4.2

so:

gcc_version=4.2

But then the test checks for

case "${is_clang}-${gcc_version}" in
     applellvm-5.1|applellvm-6.*|applellvm-7.*|applellvm-8.*)

and leaves applellvm-4.2 out of the game. And Xcode version 9 will likely be affected as well :)

The XcodeVersionInfo reveals the super complex Apple's naming scheme.

If they need clang 2.9, then something between 1.7 and 2.1 should already satisfy this condition rather than just version 5.1 and up.

[mojca (Mojca Miklavec)]

What about making this change?

configure

@@ -5465 +5465 @@
 # Note: m4 arguments are quoted with [ and ] so square brackets in shell
 # statements have to be quoted.
 case "${is_clang}-${gcc_version}" in
-     applellvm-5.1|applellvm-6.*|applellvm-7.*|applellvm-8.*)
+     applellvm-4.2|applellvm-5.1|applellvm-6.*|applellvm-7.*|applellvm-8.*)
        { $as_echo "$as_me:${as_lineno-$LINENO}: result: ok (Apple LLVM version ${gcc_version})" >&5
 $as_echo "ok (Apple LLVM version ${gcc_version})" >&6; }
        ;;

I don't know why they only added 5.1 and I don't know whether other compiler versions work, otherwise we could just as well add 4.* and 5.*. No clue what's with applellvm-9.*.

[ryandesign (Ryan Carsten Schmidt)]

The equivalent problem with valgrind and Xcode 9 was filed as #55425.

I agree it's unclear why Apple LLVM 5.1 was the earliest version added in ​https://sourceware.org/git/?p=valgrind.git;a=commit;h=5857d57571ccdcce9fd9c27c5fa7f5a86f38b304

Apple LLVM 5.1 is equivalent to clang 3.4svn, but if they accept clang >= 2.9, they should accept Apple LLVM 2.1 and later. (Apple LLVM 1.7 and 2.0 are built from LLVM 2.9svn, so it's unclear whether these contain all the clang 2.9 features required.) Note that according to XcodeVersionInfo, before version 4.2, Apple LLVM was called Apple clang, so the regex may need to be updated to accept that.

[ryandesign (Ryan Carsten Schmidt)]

​This is still a problem.

[ken-cunningham-webuse]

In 3125ff6b29f31c7ab1612ddce69a59d7bbb1a4b3/macports-ports (master):

valgrind: fix build on lion

tweak compiler selection to find compatible compilers
on lion this blacklisting leads to clang-3.4, which works

closes: #53525