Opened 13 months ago

Last modified 3 months ago

#53525 new defect

valgrind: doesn't build with an old clang

Reported by: mojca (Mojca Miklavec) Owned by: raimue (Rainer Müller)
Priority: Normal Milestone:
Component: ports Version:
Keywords: lion legacy-os Cc:
Port: valgrind

Description (last modified by 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.

Change History (6)

comment:1 Changed 13 months ago by mojca (Mojca Miklavec)

  • Description modified (diff)

comment:2 Changed 13 months ago by 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://
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'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

    $ git diff
    diff --git a/devel/valgrind/Portfile b/devel/valgrind/Portfile
    index 40a028d40d..9506df0686 100644
    a b depends_build bin:perl:perl5 
    2727# Ignore trace reports about boost, Qt and OpenMP
    2828# as they are only used for tests
     30configure.cmd       sh -x ./configure
    3031configure.args      --without-mpicc
    3233if {${build_arch} eq "i386"} {

comment:3 Changed 13 months ago by 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

> /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'

So the first test is true and we get



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



But then the test checks for

case "${is_clang}-${gcc_version}" in

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.

comment:4 Changed 8 months ago by raimue (Rainer Müller)

  • Keywords legacy-os added

comment:5 Changed 6 months ago by mojca (Mojca Miklavec)

What about making this change?

  • configure

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

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

comment:6 Changed 3 months ago by ryandesign (Ryan 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;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.

Note: See TracTickets for help on using tickets.