julia @0.3.11 fails building using MacPorts clang

[udbraumann]

As I had noticed that clang version 3.0 (tags/Apple/clang-211.10.1) shipped with Xcode 4.2 is not capable to build julia (it stops after a while complaining about a missing cholmod.h) I came up with the idea to use a newer MacPorts clang, e.g. 3.5:

sudo port -d install julia configure.compiler=macports-clang-3.5

In fact, during configuring the main component are being set CC=/opt/local/bin/clang-mp-3.5 CXX=/opt/local/bin/clang++-mp-3.5 FC=/opt/local/bin/gfortran-mp-4.9

However, julia then expects a non-existing variant of ar:

/opt/local/bin/clang-ar: No such file or directory

Instead, julia should take /opt/local/bin/llvm-ar-mp-3.5 (which in turn is a shell script pointing to /opt/local/libexec/llvm-3.5/bin/llvm-ar).

Since I have no idea how to work around this problem on the Portfile level, my first attempt was to make a copy of the llvm-ar-mp-3.5 shell script under the name clang-ar. To my surprise this did not work, it complained about an unknown switch -ru. So I gave up this without doing research on the switch variants of ar.

So my last resort was to symlink a clang-ar to /usr/bin/ar - the latter is from Xcode (I suppose), inside /opt/local/bin I called $ sudo ln -s /usr/bin/ar clang-ar. This hack worked, and also is "valid" for other clang versions, e.g. 3.4 or 3.6!

However, my experiment ended with a fatal error:

...
In file included from codegen.cpp:35:
In file included from /opt/local/libexec/llvm-3.5/include/llvm/ExecutionEngine/ExecutionEngine.h:19:
In file included from /opt/local/libexec/llvm-3.5/include/llvm/ADT/SmallVector.h:17:
/opt/local/libexec/llvm-3.5/include/llvm/ADT/iterator_range.h:37:29: error: no member named 'move' in namespace 'std'
      : begin_iterator(std::move(begin_iterator)),
                       ~~~~~^
/opt/local/libexec/llvm-3.5/include/llvm/ADT/iterator_range.h:38:27: error: no member named 'move' in namespace 'std'
        end_iterator(std::move(end_iterator)) {}
                     ~~~~~^
/opt/local/libexec/llvm-3.5/include/llvm/ADT/iterator_range.h:49:33: error: no member named 'move' in namespace 'std'
  return iterator_range<T>(std::move(x), std::move(y));
                           ~~~~~^
/opt/local/libexec/llvm-3.5/include/llvm/ADT/iterator_range.h:49:47: error: no member named 'move' in namespace 'std'
  return iterator_range<T>(std::move(x), std::move(y));
                                         ~~~~~^
In file included from codegen.cpp:35:
In file included from /opt/local/libexec/llvm-3.5/include/llvm/ExecutionEngine/ExecutionEngine.h:19:
In file included from /opt/local/libexec/llvm-3.5/include/llvm/ADT/SmallVector.h:20:
/opt/local/libexec/llvm-3.5/include/llvm/Support/MathExtras.h:21:10: fatal error: 'type_traits' file not found
#include <type_traits>
         ^
5 errors generated.
...

Any ideas?

[seanfarley (Sean Farley)]

Thanks for the report. I think you're right about the wrong ar. I'll look into this more closely and see if it's time to add some clang variants.

[ryandesign (Ryan Carsten Schmidt)]

Compiler variants should be avoided. If a port cannot be built with a particular compiler, use the compiler_blacklist_versions portgroup to blacklist those particular compilers and allow MacPorts to pick a different compiler.

In addition, it sounds like there is a bug in whichever port (possibly julia, more likely the clang-... ports) is trying to run "/opt/local/bin/clang-ar", if that doesn't exist.

[seanfarley (Sean Farley)]

Replying to ryandesign@…:

Compiler variants should be avoided. If a port cannot be built with a particular compiler, use the compiler_blacklist_versions portgroup to blacklist those particular compilers and allow MacPorts to pick a different compiler.

Ryan, for scientific ports, many of them (especially julia but see atlas for a notorious example) optimize differently for different compilers. I've had to explain this before so please try to remember for next time :-)

[petrrr]

Cc Me!

[seanfarley (Sean Farley)]

This won't be possible until 0.4 is released, so I'm going to mark this as 'invalid' because llvm 3.5 isn't really supported. julia just cut a release candidate so the wait shouldn't be too long now.