Opened 4 years ago

Closed 2 years ago

#53525 closed defect (fixed)

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 (8)

comment:1 Changed 4 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

comment:2 Changed 4 years 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 4 years 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 4 years ago by raimue (Rainer Müller)

Keywords: legacy-os added

comment:5 Changed 4 years 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 4 years 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.

comment:7 Changed 2 years ago by ryandesign (Ryan Schmidt)

comment:8 Changed 2 years ago by ken-cunningham-webuse

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.