ROOT6 : Update to first production release, 6.00.00

[cjones051073 (Chris Jones)]

Hi,

Attached patch updates root6 to the new 6.00.00 production releases ( Actually uses a slightly newer git tag, to get some fixes to the build system I first found when trying the new release and upstream and since fixed. )

Also adds a couple new variants pythia and xrootd, that where missing in the first version of this port as they did not work in the beta. Now seem fine.

Tested on OSX10.9. Might work on 10.8, probably not on anything newer.

cheers Chris

[mojca (Mojca Miklavec)]

I cannot test it, but I can commit it as is.

But we probably need to disable the build for OS X < 10.9 during pre-fetch.

[mojca (Mojca Miklavec)]

(I would of course prefer to keep support for 5.99.05-beta, but you were already very clear about your standpoint here.)

[cjones051073 (Chris Jones)]

Regarding older OSX releases, one thing I should have commented on is I did see during the configuration step ROOT6 now checks to see if c++11 is supported or not. What it does if that fails I do not know, but I would rather not just disable <10.9 systems without first finding out ? For instance I have a suspicion that OSX10.8 might just now work (upstream seems to claim this), but it is possible the current compiler blacklists might prevent this without some further tweaking. Unfortunately, as I only have access to OSX10.9 this is not something I can really test myself....

[cjones051073 (Chris Jones)]

Maybe if you agree you could commit this, and we see what the build bots make of it ;)

[mojca (Mojca Miklavec)]

This is how llvm-3.5 prevents the wrong setup, something similar would be needed for ROOT 6 (after a bit of a clean up):

# llvm-3.5 and later requires a C++11 runtime
compiler.blacklist *gcc* {clang < 300}

# TODO: Check ${configure.cxx_stdlib} directly once MacPorts 2.3 is released
platform darwin {
    # Note that we are forcing this choice.  This means that anything linking
    # against llvm-3.5 needs to also be using libc++.  This is possibly
    # problematic, but luckily there is just a limited set of such dependents.

    if {[info exists configure.cxx_stdlib]} {
        configure.cxx_stdlib libc++
    }

    depends_lib-append port:libcxx
}

pre-fetch {
    if {(${os.major} < 13 && ! [info exists configure.cxx_stdlib]) ||
        (! [file exists /usr/lib/libc++.dylib])} {
        ui_error "$name requires a C++11 runtime, which your configuration does not allow"
        error "unsupported configuration"
    }
}

[mojca (Mojca Miklavec)]

I can certainly make the first commit now and see what happens on 10.8. But we might at least want to check what to do with cxx_stdlib.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

I can certainly make the first commit now and see what happens on 10.8. But we might at least want to check what to do with cxx_stdlib.

Yeah... Now the new MP is out I did put it on my mental to do list to see if things could be cleaned up a bit.... I don't really have time now to do that, so figured as what is there seems to work fine, it could wait a bit.... ?

[mojca (Mojca Miklavec)]

There's something I don't quite understand. llvm-3.5 packages seem to build on Lion as well, they weren't working a while ago:

• ​http://packages.macports.org/llvm-3.5/

[cjones051073 (Chris Jones)]

Replying to mojca@…:

This is how llvm-3.5 prevents the wrong setup, something similar would be needed for ROOT 6 (after a bit of a clean up):

# llvm-3.5 and later requires a C++11 runtime
compiler.blacklist *gcc* {clang < 300}

# TODO: Check ${configure.cxx_stdlib} directly once MacPorts 2.3 is released
platform darwin {
    # Note that we are forcing this choice.  This means that anything linking
    # against llvm-3.5 needs to also be using libc++.  This is possibly
    # problematic, but luckily there is just a limited set of such dependents.

    if {[info exists configure.cxx_stdlib]} {
        configure.cxx_stdlib libc++
    }

    depends_lib-append port:libcxx
}

pre-fetch {
    if {(${os.major} < 13 && ! [info exists configure.cxx_stdlib]) ||
        (! [file exists /usr/lib/libc++.dylib])} {
        ui_error "$name requires a C++11 runtime, which your configuration does not allow"
        error "unsupported configuration"
    }
}

Yeah. As I said though before going down this road I would like to check what actually happens on older systems first. It might be upstream have found a way to support some systems older than 10.9 ...

[mojca (Mojca Miklavec)]

I'm adding the clang expert to CC.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

I'm adding the clang expert to CC.

Lucky Jeremy.... ;)

Seriously though, exactly whats the question you have for him ?

[mojca (Mojca Miklavec)]

r120690, so let's see what the buildbots have to say ;)

I'm almost sure that we'll need a minor patch, but I'm curious as well.

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

Replying to mojca@…:

I'm adding the clang expert to CC.

Lucky Jeremy.... ;)

Seriously though, exactly whats the question you have for him ?

Given that clang-3.5 can now be compiled on 10.7 (which wasn't the case between January 5th and May 28th) something is telling me that ROOT 6 will also work there.

Clang even compiles on 10.6 (but I seem to remember that a few other things go wrong there, mainly a few functions used by ROOT are missing in the Cocoa api).

[mojca (Mojca Miklavec)]

Chris, do you happen to know which version (svn revision) of clang is being used in ROOT 6?

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Chris, do you happen to know which version (svn revision) of clang is being used in ROOT 6?

I don't know exactly (and anyway Clang/LLVM have, hmm, interesting ideas on versioning anyway). I think its pretty up to date though...

[mojca (Mojca Miklavec)]

But the questions for Jeremy would be to clean-up the llvm-3.5 according to the comment (TODO: Check ${configure.cxx_stdlib} directly once MacPorts 2.3 is released), so that we could cheat and copy the relevant lines from his port to ROOT 6. And to tell us the secret how to build clang/cling on 10.7.

[mojca (Mojca Miklavec)]

Not that it really matters, but the ​snow leopard build fails with:

In file included from /path/to/root-aaf9b65/core/meta/src/TClass.cxx:50:
/path/to/root-aaf9b65/core/meta/inc/TProtoClass.h:59: error: invalid pure specifier (only `= 0' is allowed) before ‘;’ token
/path/to/root-aaf9b65/core/meta/inc/TProtoClass.h:60: error: invalid pure specifier (only `= 0' is allowed) before ‘;’ token
/path/to/root-aaf9b65/core/meta/inc/TProtoClass.h:59: error: initializer specified for non-virtual method ‘TProtoClass::TProtoClass(const TProtoClass&)’
/path/to/root-aaf9b65/core/meta/inc/TProtoClass.h:60: error: initializer specified for non-virtual method ‘TProtoClass& TProtoClass::operator=(const TProtoClass&)’
/opt/local/bin/cmake -E cmake_progress_report /path/to/build/CMakeFiles

[cjones051073 (Chris Jones)]

OK... Not too surprised by that...

[mojca (Mojca Miklavec)]

​Lion is stuck at:

[  1%] In file included from /path/to/root-aaf9b65/interpreter/llvm/src/lib/IRReader/IRReader.cpp:15:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/Bitcode/ReaderWriter.h:17:
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/Support/ErrorOr.h:25:10: fatal error: 'type_traits' file not found
#include <type_traits>
         ^

​Mountain Lion has problems with:

[  0%] /opt/local/bin/cmake -E make_directory /path/to/build/LLVM-install
/opt/local/bin/cmake -E make_directory /path/to/build/LLVM/tmp
Building CXX object core/cont/CMakeFiles/Cont.dir/src/TArray.cxx.o
cc1objplus: error: unrecognized command line option "-std=c++11"

[mojca (Mojca Miklavec)]

Building on Lion with configure.compiler=macports-clang-3.5 fails with:

[  0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/lib/Support/APFloat.cpp:15:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/APFloat.h:20:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/APInt.h:19:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/ArrayRef.h:14:
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:188:15: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      *Dest = ::std::move(*I);
              ^~~~~~~~~~~
              move
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:185:14: note: 'move' declared here
  static It2 move(It1 I, It1 E, It2 Dest) {
             ^
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:203:17: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      *--Dest = ::std::move(*--E);
                ^~~~~~~~~~~
                move
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:185:14: note: 'move' declared here
  static It2 move(It1 I, It1 E, It2 Dest) {
             ^
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:216:32: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      ::new ((void*) &*Dest) T(::std::move(*I));
                               ^~~~~~~~~~~
                               move
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:185:14: note: 'move' declared here
  static It2 move(It1 I, It1 E, It2 Dest) {
             ^
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:251:37: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      ::new ((void*) this->end()) T(::std::move(Elt));
                                    ^~~~~~~~~~~
                                    move

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Building on Lion with configure.compiler=macports-clang-3.5 fails with:

[  0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/lib/Support/APFloat.cpp:15:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/APFloat.h:20:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/APInt.h:19:
In file included from /path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/ArrayRef.h:14:
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:188:15: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      *Dest = ::std::move(*I);
              ^~~~~~~~~~~
              move
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:185:14: note: 'move' declared here
  static It2 move(It1 I, It1 E, It2 Dest) {
             ^
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:203:17: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      *--Dest = ::std::move(*--E);
                ^~~~~~~~~~~
                move
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:185:14: note: 'move' declared here
  static It2 move(It1 I, It1 E, It2 Dest) {
             ^
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:216:32: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      ::new ((void*) &*Dest) T(::std::move(*I));
                               ^~~~~~~~~~~
                               move
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:185:14: note: 'move' declared here
  static It2 move(It1 I, It1 E, It2 Dest) {
             ^
/path/to/root-aaf9b65/interpreter/llvm/src/include/llvm/ADT/SmallVector.h:251:37: error: no member named 'move' in namespace 'std'; did you mean simply 'move'?
      ::new ((void*) this->end()) T(::std::move(Elt));
                                    ^~~~~~~~~~~
                                    move

Thats definitely a c++11 support issue. Reduces a bit my hope that 10.8 will work...

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

Replying to mojca@…:

Chris, do you happen to know which version (svn revision) of clang is being used in ROOT 6?

I don't know exactly (and anyway Clang/LLVM have, hmm, interesting ideas on versioning anyway). I think its pretty up to date though...

Pretty up to day is pretty uninformative given that ROOT has been released on 30th May and clang-3.5 only builds on the buildbot since 28th May (version 3.5-r206638). (But I don't know if it builds because something has changed in the clang sources or because some modifications were made in MacPorts.)

[mojca (Mojca Miklavec)]

Btw, I'm getting the following unrelated warning:

CMake Warning:
  Manually-specified variables were not used by the project:

    reflex

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Btw, I'm getting the following unrelated warning:

CMake Warning:
  Manually-specified variables were not used by the project:

    reflex

yeah, I saw that. reflex is somewhat depreciated so I also put that on my 'worry about some other time' pile.

FWIW, OSX10.9 build bot worked fine.

Chris

[mojca (Mojca Miklavec)]

Bingo! By copying the relevant (outdated) lines from the llvm-3.5 port + fetching the latest commit tag from ROOT 6 I'm already waaay past the previous problem. I'm not sure which of the two did the trick and I'll be able to tell "by tomorrow" ;) where the next failure would be.

[mojca (Mojca Miklavec)]

Comments in ​https://github.com/root-mirror/root/tree/master/interpreter/llvm/src seem to suggest that llvm has last been synced with r202469 (Update to llvm/clang r202469. on 3rd March) That looks approximately 3 months old.

[mojca (Mojca Miklavec)]

a patch hopefully allowing to build root6 on OS X < 10.9

[mojca (Mojca Miklavec)]

I attached a patch that I'm using for building ROOT 6 on 10.7. I'm not yet sure which of the two changes actually helped, but most likely it worked thanks to the code from llvm port. Maybe there is no need to fetch the latest version of ROOT.

[mojca (Mojca Miklavec)]

There is actually a stupid mistake on ​Snow Leopard: it tries to compile ROOT 6 with the default gcc-4.2. The blacklist is good enough for Lion, but not strict enough for SL.

We need to blacklist the gcc compiler, but I'm not sure if/how that interferes with the choice of the Fortran compiler, so that needs some more testing. We probably also need to remove macports-clang-3.3 from compiler.fallback.

[mojca (Mojca Miklavec)]

I committed r120703. The problem is that this doesn't seem to be sufficient on ​Lion:

In file included from input_line_4:1:
In file included from /path/to/root-aaf9b65/core/base/inc/Rtypes.h:30:
In file included from /path/to/root-aaf9b65/core/base/inc/Rtypeinfo.h:32:
In file included from /usr/bin/../lib/c++/v1/typeinfo:61:
/usr/bin/../lib/c++/v1/exception:146:5: error: an attribute list cannot appear here
    _LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
    ^~~~~~~~~~~~~~~~
/usr/bin/../lib/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
#  define _LIBCPP_NORETURN [[noreturn]]
                           ^~~~~~~~~~~~

There are only two possible explanations: either one should use a more recent ROOT version or the default compiler should be blacklisted. I suspect the problem must be in too old compiler (since the compilation succeeded when using macports-clang-3.5).

But then again this fails after cling has already been compiled. In all honesty the new compiler could be used to finish the build ;).

10.8 fails at the same point as before the commit.

[mojca (Mojca Miklavec)]

I'm sorry, the new addition messed up with the code inside darwin that comes later in the Portfile. One part of the code still tries to set libstdc++, the other one tries to force libc++. And c++11 is switched on and off – I'm not exactly sure how that switch is supposed to work if non-C++11 compilers apparently don't work anyway. This has to be fixed.

I didn't test versions 3.3 and 3.4 yet, but I suggest the following blacklist:

compiler.blacklist-append *gcc* {clang < 500} macports-clang-2.9 macports-clang-3.0 macports-clang-3.1 macports-clang-3.2 macports-clang-3.3
compiler.fallback-append macports-clang-3.5 macports-clang-3.4

The configure option -Dreflex=ON should be removed. There is no longer any genreflex script in ROOT 6, it seems.

[jeremyhu (Jeremy Huddleston Sequoia)]

root6-libc++.patch​

1) You copy pasted everything from llvm-3.5, including the comment ;)

2) The checks for support of that variable aren't needed any more because it's supported in base 2.3.0 now, so you can remove the backwards compatible hacks.

3) What links against root, and what other libraries does root use? This will have a HUGE impact on that because anything that links against root6's libraries and any C++ libraries that root6 uses will need to use the libc++ runtime as well.

---

Given that clang-3.5 can now be compiled on 10.7 (which wasn't the case between January 5th and May 28th) something is telling me that ROOT 6 will also work there.

I've been using clang-3.5 fine on SnowLeopard and later for quite some time. The issue is that you needed base 2.3 (trunk at the time), and you needed to chose libc++ as your C++ runtime in macports.conf (by setting "cxx_stdlib libc++").

---

interferes with the choice of the Fortran compiler

Ugg. See ​https://trac.macports.org/wiki/PortfileRecipes#fortran for setting up the fortran compiler.

---

compiler.fallback-append macports-clang-3.5 macports-clang-3.4

Why append 3.5 before 3.4? Also 3.4 is already in the fallback list (it's actually preferred over 3.3).

[cjones051073 (Chris Jones)]

You patch root6-libc++.patch forces a dependency on the libc++ port even on OSX 10.9, where it is not required. We should update this to only add this dependency on platforms that really need it. You should also merge both your new and the previous Darwin block into one single one....

[cjones051073 (Chris Jones)]

I've attached a new patch that cleans up the Darwin block. What was there was to some degree a relic from the original root5 port anyway.

• One systems where libc++ is already in use, it does nothing.

• On those where it isn't, and configure.cxx_stdlib is available, it uses it to force libc++ and depend on the libcxx port.

• Otherwise, it just disables the use of c++11 and libc++

Of the 3 above, I can only really test the first option, on my OSX10.9 system, so I am just assuming the other two are what we want.. Please of course feel free to changes things once you test a bit more, but please make sure that on OSX10.9 your updates do not change the behaviour in anyway, I want that OS to be as 'un-fiddled' with as possible ;)

Chris

[mojca (Mojca Miklavec)]

Replying to jeremyhu@…:

1) You copy pasted everything from llvm-3.5, including the comment ;)

Yes, I'm aware of that. But I don't yet feel comfortable messing with this yet: I'm not yet exactly sure how this `[info exists configure.cxx_stdlib]" works. I guessed your code must work on both 2.3 and earlier, so I copied everything literally for now. It worked for me and I wrote "(copied from llvm-3.5)" in order not to forget to check how you would change the port ;)

2) The checks for support of that variable aren't needed any more because it's supported in base 2.3.0 now, so you can remove the backwards compatible hacks.

Does that mean that I should simply change

if {[info exists configure.cxx_stdlib]} {
    configure.cxx_stdlib libc++
}

into

configure.cxx_stdlib libc++

I don't know what the proper change is which is why I didn't dare to do it (I see Chris' patch, but I need to figure out how this works exactly).

3) What links against root, and what other libraries does root use? This will have a HUGE impact on that because anything that links against root6's libraries and any C++ libraries that root6 uses will need to use the libc++ runtime as well.

At the moment I'm not aware of any port linking against root yet, even though some ports might start using it in future (iAida, Gate, ...).

Root depends on the following ports:

expat, gmp, giflib, jpeg, libpng, lzma, pcre, tiff, zlib, xz, libgcc, graphviz, gsl, openssl, libxml2

even though with some tricks this list could be minimized to almost zero; I believe that root ships with most of these libraries, so one can simply use the built-in version; but then this would be done on < 10.9 only.

I've been using clang-3.5 fine on SnowLeopard and later for quite some time. The issue is that you needed base 2.3 (trunk at the time), and you needed to chose libc++ as your C++ runtime in macports.conf (by setting "cxx_stdlib libc++").

Thank you for explanation.

interferes with the choice of the Fortran compiler

Ugg. See ​https://trac.macports.org/wiki/PortfileRecipes#fortran for setting up the fortran compiler.

I think it's done that way already.

Anyway, if I blacklist *gcc*, Fortran seems to compile just fine.

compiler.fallback-append macports-clang-3.5 macports-clang-3.4

Why append 3.5 before 3.4? Also 3.4 is already in the fallback list (it's actually preferred over 3.3).

I used it just in case (the higher version should have a better chance to work? ;), but I forgot that 3.5 is still a development version, so yes, 3.4 should be listed before 3.5.

The weird thing that I don't understand is that when I blacklist all gcc as well as system compiler on Lion, macports-clang-3.3 was used (unless I blacklisted macports-clang-3.3), so I'm not sure if 3.4 is actually preferred over 3.3. But now that you mentioned it I'm curious to double check whether 3.3 or 3.4 would be selected by default.

I actually need to check whether 3.3 works at all. The default compiler on Lion apparently doesn't.

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

You patch root6-libc++.patch forces a dependency on the libc++ port even on OSX 10.9, where it is not required.

Ah, sorry. Yes, libcxx dependency should be removed.

You should also merge both your new and the previous Darwin block into one single one....

I only noticed that later, but waited for more input as I'm not sure that I understand already how this works.

I've attached a new patch that cleans up the Darwin block. What was there was to some degree a relic from the original root5 port anyway.

Thank you.

• One systems where libc++ is already in use, it does nothing.

Which block does that exactly?

• On those where it isn't, and configure.cxx_stdlib is available, it uses it to force libc++ and depend on the libcxx port.

OK.

• Otherwise, it just disables the use of c++11 and libc++

When exactly would I want to disable the use of c++11? Would that work at all? (I'm not sure what -Dc++11=ON or -Dc++11=OFF do to be honest.)

I want that OS to be as 'un-fiddled' with as possible ;)

I agree with that. I just need to learn how this machinery works.

[cjones051073 (Chris Jones)]

• One systems where libc++ is already in use, it does nothing.

Which block does that exactly?

Ah yes, my mistake. I'll fix that ;)

[cjones051073 (Chris Jones)]

I've updated the patch so it now really does do nothing on platforms where libc++ is already the default.

[cjones051073 (Chris Jones)]

• Otherwise, it just disables the use of c++11 and libc++

When exactly would I want to disable the use of c++11? Would that work at all? (I'm not sure what -Dc++11=ON or -Dc++11=OFF do to be honest.)

Most probably this is not needed. In fact if we are OK with removing the need to check if configure.cxx_stdlib is present (i.e. the user is running the latest MP release) then the Darwin block could probably be shortened to just

platform darwin {
    if { ${configure.cxx_stdlib} ne "libc++" } {
         configure.cxx_stdlib libc++
         depends_lib-append port:libcxx
    }
}

[mojca (Mojca Miklavec)]

Just to make sure that I understand properly.

Is configure.cxx_stdlib defined only on 2.3, so it can safely be assumed that it's defined now (and [info exists configure.cxx_stdlib] may be dropped)?

Is the value of equal to libc++ on 10.9 (and later) and libstdc++ everywhere else?

When configure.cxx_stdlib is already set to libc++, we don't need/want port:libcxx or anything else.

[mojca (Mojca Miklavec)]

Both macports-clang-3.3 and macports-clang-3.4 seem to work (the clang shipped with Lion seems to fail), but I would prefer if version 3.4 was used. If I don't blacklist version 3.3, then version 3.3 is used. Is there any way to change the order of preference?

[mojca (Mojca Miklavec)]

Jeremy, this is from portconfigure.tcl:

# internal function to choose compiler fallback list based on platform
proc portconfigure::get_compiler_fallback {} {
    global xcodeversion macosx_deployment_target default_compilers configure.sdkroot
    if {[info exists default_compilers]} {
        return $default_compilers
    } elseif {$xcodeversion eq "none" || $xcodeversion eq ""} {
        return {cc}
    } elseif {[vercmp $xcodeversion 5.0] >= 0} {
        return {clang macports-llvm-gcc-4.2 apple-gcc-4.2 macports-clang-3.3}
    } elseif {[vercmp $xcodeversion 4.2] >= 0} {
        return {clang llvm-gcc-4.2 apple-gcc-4.2 macports-clang-3.3}
    } elseif {[vercmp $xcodeversion 4.0] >= 0} {
        return {llvm-gcc-4.2 clang gcc-4.2 macports-clang-3.3 apple-gcc-4.2}
    } elseif {[vercmp $xcodeversion 3.2] >= 0} {
        if {[string match *10.4u* ${configure.sdkroot}]} {
            return {gcc-4.0}
        } else {
            return {gcc-4.2 clang llvm-gcc-4.2 macports-clang-3.3 macports-llvm-gcc-4.2 apple-gcc-4.2 gcc-4.0}
        }
    } elseif {[vercmp $xcodeversion 3.0] >= 0} {
        return {gcc-4.2 apple-gcc-4.2 gcc-4.0 macports-clang-3.3}
    } else {
        return {apple-gcc-4.2 gcc-4.0 gcc-3.3 macports-clang-3.3}
    }
}

I'm using xcode 4.6.3. The return value seems to be

{clang llvm-gcc-4.2 apple-gcc-4.2 macports-clang-3.3}

No macports-clang-3.4 there. And in fact 3.3 is always used if I disable the system clang (unless I blacklist macports-clang-3.3).

[cjones051073 (Chris Jones)]

I am sure you have already, but have you experimented with changing the order in the compiler fallback list ?

[mojca (Mojca Miklavec)]

I tried it, but it doesn't make a difference. The fallback list is only used whet MacPorts runs out of "ideas" which compiler to use. And because macports-clang-3.3 is on the list of default compilers to try (see portconfigure above), it doesn't even start looking into the fallback list.

[mojca (Mojca Miklavec)]

What about the following? I would guess that this chunk of code is still needed?

pre-fetch {
    if { ![file exists /usr/lib/libc++.dylib] } {
        ui_error "$name requires a C++11 runtime, which your configuration does not allow"
        error "unsupported configuration"
    }
}

[cjones051073 (Chris Jones)]

Replying to mojca@…:

I tried it, but it doesn't make a difference. The fallback list is only used whet MacPorts runs out of "ideas" which compiler to use. And because macports-clang-3.3 is on the list of default compilers to try (see portconfigure above), it doesn't even start looking into the fallback list.

Hmmm. that seems a little backwards to me. If asked, I would have guess the user specified fallback list would have been used, in the order given, *before* resorting to the defaults...

[cjones051073 (Chris Jones)]

Replying to mojca@…:

What about the following? I would guess that this chunk of code is still needed?

pre-fetch {
    if { ![file exists /usr/lib/libc++.dylib] } {
        ui_error "$name requires a C++11 runtime, which your configuration does not allow"
        error "unsupported configuration"
    }
}

Have you changed that ? It used to be

pre-fetch {
    if {(${os.major} < 13 && ! [info exists configure.cxx_stdlib]) ||
        (! [file exists /usr/lib/libc++.dylib])} {
        ui_error "$name requires a C++11 runtime, which your configuration does not allow"
        error "unsupported configuration"
    }
}

Chris

[mojca (Mojca Miklavec)]

Yes, I changed it. Because from what I uderstand [info exists configure.cxx_stdlib] is always true since MacPorts 2.3.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Yes, I changed it. Because from what I uderstand [info exists configure.cxx_stdlib] is always true since MacPorts 2.3.

But is it then correct to *always* require /usr/lib/libc++.dylib is present, which is what it now does ?

I thought the idea of using the libc++ port was to use that as an alternative when it was not available ? Or does that port actually provide this library ?

Chris

[cjones051073 (Chris Jones)]

Replying to jonesc@…:

Replying to mojca@…:

I tried it, but it doesn't make a difference. The fallback list is only used whet MacPorts runs out of "ideas" which compiler to use. And because macports-clang-3.3 is on the list of default compilers to try (see portconfigure above), it doesn't even start looking into the fallback list.

Hmmm. that seems a little backwards to me. If asked, I would have guess the user specified fallback list would have been used, in the order given, *before* resorting to the defaults...

If also black listing macports clang 3.3 means 3.4 is then used, is this not a solution, or does it lead to other problems ?

[cjones051073 (Chris Jones)]

I just tried installing livcxx to just see what it contains, but on OSX10.9 that doesn't help ;)

MacBookPro ~/Documents/LHCb/LHCbDocs/LHCbPerformancePaper > sudo port contents libcxx
Port libcxx contains:
  /opt/local/share/doc/libcxx/README.txt
MacBookPro ~/Documents/LHCb/LHCbDocs/LHCbPerformancePaper > cat /opt/local/share/doc/libcxx/README.txt
libcxx is an empty port on this OS version because the functionality is already provided by the OS.

What does it provide for you, just for my education ?

Chris

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

Replying to mojca@…:

Yes, I changed it. Because from what I uderstand [info exists configure.cxx_stdlib] is always true since MacPorts 2.3.

But is it then correct to *always* require /usr/lib/libc++.dylib is present, which is what it now does ?

I thought the idea of using the libc++ port was to use that as an alternative when it was not available ? Or does that port actually provide this library ?

I guess you are right. All that the libcxx port provides on my system is a README file with

libcxx is an empty port on this OS version because the functionality is already provided by the OS.

I'll remove the part with pre-fetch and see what happens on 10.6.

If also black listing macports clang 3.3 means 3.4 is then used, is this not a solution, or does it lead to other problems ?

It shouldn't lead to other problems. And I plan to do just that (on the other hand it seems a bit unfair to blacklist 3.3 as that compiler works in principle, it's just that 3.4 should probably be the preferred one).

[mojca (Mojca Miklavec)]

I committed r120764. Let's see what the Lion and Snow Leopard buildbots have to say. I'm almost sure that Mountain Lion will still be broken. Maybe we also need to blacklist the system compiler on 10.8, but I'm not sure which one. We should ask someone with that OS to test it.

[cjones051073 (Chris Jones)]

Looks like all but 10.6 worked OK ....

Do you know how to get a log from the buildbot system ? When I try I seem to just end up going in circles searching ...

[mojca (Mojca Miklavec)]

The build log is here:

• ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/26843

The relevant part is under Steps and Logfiles -> compile -> stdio (and compile -> progress to quickly check which ports failed and which ones compiled).

-- The C compiler identification is Clang 3.4.0
-- The CXX compiler identification is Clang 3.4.0
CMake Warning at /opt/local/share/cmake-2.8/Modules/Platform/Darwin.cmake:316 (message):
  The SDK Library/Frameworks path

   /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks

  is not set up correctly on this system.  This is known to occur when
  installing Xcode 3.2.6:

   http://bugs.python.org/issue14018

  The problem may cause build errors that report missing system frameworks.
  Fix your SDK symlinks to resolve this issue and avoid this warning.
Call Stack (most recent call first):
  /opt/local/share/cmake-2.8/Modules/CMakeSystemSpecificInformation.cmake:36 (include)
  CMakeLists.txt:5 (project)


-- Check for working C compiler: /opt/local/bin/clang-mp-3.4
-- Check for working C compiler: /opt/local/bin/clang-mp-3.4 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/local/bin/clang++-mp-3.4
-- Check for working CXX compiler: /opt/local/bin/clang++-mp-3.4 -- broken
CMake Error at /opt/local/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "/opt/local/bin/clang++-mp-3.4" is not able to compile a
  simple test program.

  It fails with the following output:

   Change Dir: /opt/local/var/macports/build/_opt_mports_dports_science_root6/root6/work/build/CMakeFiles/CMakeTmp

  

  Run Build Command:/usr/bin/make "cmTryCompileExec828241131/fast"

  /usr/bin/make -f CMakeFiles/cmTryCompileExec828241131.dir/build.make
  CMakeFiles/cmTryCompileExec828241131.dir/build

  /opt/local/bin/cmake -E cmake_progress_report
  /opt/local/var/macports/build/_opt_mports_dports_science_root6/root6/work/build/CMakeFiles/CMakeTmp/CMakeFiles
  1

  Building CXX object
  CMakeFiles/cmTryCompileExec828241131.dir/testCXXCompiler.cxx.o

  /opt/local/bin/clang++-mp-3.4 -pipe -Os -arch x86_64 -stdlib=libc++
  -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -o
  CMakeFiles/cmTryCompileExec828241131.dir/testCXXCompiler.cxx.o -c
  /opt/local/var/macports/build/_opt_mports_dports_science_root6/root6/work/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx


  Linking CXX executable cmTryCompileExec828241131

  /opt/local/bin/cmake -E cmake_link_script
  CMakeFiles/cmTryCompileExec828241131.dir/link.txt --verbose=1

  /opt/local/bin/clang++-mp-3.4 -pipe -Os -arch x86_64 -stdlib=libc++
  -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib
  -Wl,-headerpad_max_install_names -arch x86_64
  CMakeFiles/cmTryCompileExec828241131.dir/testCXXCompiler.cxx.o -o
  cmTryCompileExec828241131

  ld: library not found for -lc++

  clang: error: linker command failed with exit code 1 (use -v to see
  invocation)

  make[1]: *** [cmTryCompileExec828241131] Error 1

  make: *** [cmTryCompileExec828241131/fast] Error 2

  

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:5 (project)


-- Configuring incomplete, errors occurred!

[mojca (Mojca Miklavec)]

The following looks like missing libc++:

ld: library not found for -lc++

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to mojca@…:

Jeremy, this is from portconfigure.tcl: <snip /> I'm using xcode 4.6.3. The return value seems to be

{clang llvm-gcc-4.2 apple-gcc-4.2 macports-clang-3.3}

No macports-clang-3.4 there. And in fact 3.3 is always used if I disable the system clang (unless I blacklist macports-clang-3.3).

What version do you have?

r118085 r118735 r119034

---

But is it then correct to *always* require /usr/lib/libc++.dylib is present, which is what it now does ?

yes

I thought the idea of using the libc++ port was to use that as an alternative when it was not available ? Or does that port actually provide this library ?

Yes.

What does it provide for you, just for my education ?

The libcxx port provides the user with a way to install /usr/lib/libc++.dylib on Snow Leopard. It's just a stub on Lion and later.

---

I'll remove the part with pre-fetch and see what happens on 10.6.

No, it's needed for Snow Leopard users if you're going to use libc++

[jeremyhu (Jeremy Huddleston Sequoia)]

Why are you doing this?

# List of possible clang versions that work
set clang_versions { 3.3 3.4 3.5 }

# Define the available variants
foreach ver ${clang_versions} {
    set ver_no_dot [join [split ${ver} "."] ""]
    set variant_line {variant clang${ver_no_dot} description "Compile using MacPorts clang ${ver}"}
    foreach over ${clang_versions} {
        if { ${ver} == ${over} } { continue }
        set over_no_dot [join [split ${over} "."] ""]
        append variant_line " conflicts clang${over_no_dot}"
    }
    append variant_line { { } }
    eval $variant_line
}

# Is a variant active ?
set active_clang_variant ""
foreach ver ${clang_versions} {
    set ver_no_dot [join [split ${ver} "."] ""]
    if {[variant_isset clang${ver_no_dot}]} {
        set active_clang_variant ${ver}
    }
}

# If so, set it up.
if { ${active_clang_variant} != "" } {
    configure.compiler      macports-clang-${active_clang_variant}
    # TODO
    # configure.args-append   --with-llvm-config="${prefix}/bin/llvm-config-mp-"${active_clang_variant}
    depends_run-append      port:clang-${active_clang_variant}
}

[mojca (Mojca Miklavec)]

Replying to jeremyhu@…:

Replying to mojca@…:

I'm using xcode 4.6.3. The return value seems to be

{clang llvm-gcc-4.2 apple-gcc-4.2 macports-clang-3.3}

No macports-clang-3.4 there. And in fact 3.3 is always used if I disable the system clang (unless I blacklist macports-clang-3.3).

What version do you have?

r118085 r118735 r119034

Version 2.3.0. The file says it's r118016, so it's indeed older. It must be this one: tags/release_2_3_0/base/src/port1.0/portconfigure.tcl​

The libcxx port provides the user with a way to install /usr/lib/libc++.dylib on Snow Leopard. It's just a stub on Lion and later.

I'll remove the part with pre-fetch and see what happens on 10.6.

No, it's needed for Snow Leopard users if you're going to use libc++

I'm confused now. Assuming that I use

depends_lib-append port:libcxx

Why do I still need to check for [file exists /usr/lib/libc++.dylib] then? To throw an error on 10.5 and 10.4? Or does it also make a difference on 10.6?

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Why are you doing this?

# List of possible clang versions that work
set clang_versions { 3.3 3.4 3.5 }

# Define the available variants
foreach ver ${clang_versions} {
    set ver_no_dot [join [split ${ver} "."] ""]
    set variant_line {variant clang${ver_no_dot} description "Compile using MacPorts clang ${ver}"}
    foreach over ${clang_versions} {
        if { ${ver} == ${over} } { continue }
        set over_no_dot [join [split ${over} "."] ""]
        append variant_line " conflicts clang${over_no_dot}"
    }
    append variant_line { { } }
    eval $variant_line
}

# Is a variant active ?
set active_clang_variant ""
foreach ver ${clang_versions} {
    set ver_no_dot [join [split ${ver} "."] ""]
    if {[variant_isset clang${ver_no_dot}]} {
        set active_clang_variant ${ver}
    }
}

# If so, set it up.
if { ${active_clang_variant} != "" } {
    configure.compiler      macports-clang-${active_clang_variant}
    # TODO
    # configure.args-append   --with-llvm-config="${prefix}/bin/llvm-config-mp-"${active_clang_variant}
    depends_run-append      port:clang-${active_clang_variant}
}

The root ports have always provided these variants, to allow users to pick the MP clang as their compiler, if thats the one they wish to use. Whats your problem with the above ?

[mojca (Mojca Miklavec)]

I also don't quite understand the difference between these variants. Why would one user want to explicitly specify port install root6 +clang35? Are there any real benefits of doing that? Would ROOT behave differently in different situations?

I somewhat understand that there probably was a big difference when the default compiler was still gcc.

But the thing that puzzles me most is the runtime dependency on the compiler. (I had to uninstall root5+clang30 before I was able to uninstall clang-3.0.)

Unrelated: Jeremy, would you be willing to take a look at the standalone cling port (there is a separate ticket for that)? It's basically one of the latest versions of clang with a few patches on top. If we add it, it should be set up in almost the same fashion as other llvm/clang ports, supporting port select etc.

What's currently in #43530 has a bunch of issues, including the fact that everything gets installed to ${prefix}/bin. I have to admit that I'm more interested in cling than I'm in ROOT. Installing ROOT serves the purpose, but there might be other users who aren't interested in the rest of functionality of ROOT. Cling is similar to "irb" for ruby or like running python and manually entering expressions line-by-line.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

I also don't quite understand the difference between these variants. Why would one user want to explicitly specify port install root6 +clang35? Are there any real benefits of doing that? Would ROOT behave differently in different situations?

Don't forget the compiler used to build ROOT is then the same compiler used interactively by ROOT when it is asked to compiler scripts etc. Thats why the user might have a wish to pick a particular compiler.

I somewhat understand that there probably was a big difference when the default compiler was still gcc.

But the thing that puzzles me most is the runtime dependency on the compiler. (I had to uninstall root5+clang30 before I was able to uninstall clang-3.0.)

Same reason as above. The compiler is needed not only at build time, but at runtime, due to the interactive environment.

Chris

[cjones051073 (Chris Jones)]

Replying to mojca@…:

The build log is here:

• ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/26843

The relevant part is under Steps and Logfiles -> compile -> stdio (and compile -> progress to quickly check which ports failed and which ones compiled).

Yeah. I can find that myself ;) But how do you then manage to actually view the log ? its so big it just hangs up my browser....

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Replying to mojca@…:

I also don't quite understand the difference between these variants. Why would one user want to explicitly specify port install root6 +clang35? Are there any real benefits of doing that? Would ROOT behave differently in different situations?

Don't forget the compiler used to build ROOT is then the same compiler used interactively by ROOT when it is asked to compiler scripts etc. Thats why the user might have a wish to pick a particular compiler.

Yes, but the variants set configure.compiler, so the variants select the used compiler. We should try to avoid doing that as much as possible as it's a nightmare to maintain. If you intend to select the compiler used by root, that's fine, but don't set configure.compiler in that case.

Yeah. I can find that myself ;) But how do you then manage to actually view the log ? its so big it just hangs up my browser....

curl -LO ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/26843/steps/compile/logs/stdio/text

Then open it in a pager or text editor ... then go yell at WebKit to not suck.

[cjones051073 (Chris Jones)]

Yes, but the variants set configure.compiler, so the variants select the used compiler. We should try to avoid doing that as much as possible as it's a nightmare to maintain. If you intend to select the compiler used by root, that's fine, but don't set configure.compiler in that case.

Sorry, I must be missing something. What other method is there of selecting the compiler to use other than setting configure.compiler ? I thought that was the correct way to do it...

[cjones051073 (Chris Jones)]

Yeah. I can find that myself ;) But how do you then manage to actually view the log ? its so big it just hangs up my browser....

curl -LO ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/26843/steps/compile/logs/stdio/text

Then open it in a pager or text editor ... then go yell at WebKit to not suck.

Does that actually work for you ? All I get is

MacBookPro ~ > /usr/bin/curl -LO ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/26843/steps/compile/logs/stdio/text
curl: (1) Protocol ​https not supported or disabled in lib curl

Same deal with both system and MP curl version...

Chris

[mojca (Mojca Miklavec)]

wget --no-check-certificate -O root6-snow.txt "https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/26843/steps/compile/logs/stdio/text"

curl doesn't work for me either, same problem.

[mojca (Mojca Miklavec)]

Ah, OK, it seems clearer now:

$ sudo port deactivate clang-3.5
--->  Deactivating clang-3.5 @3.5-r206638_3+analyzer+arm_runtime+assertions
--->  Cleaning clang-3.5

$ root6
ERROR in cling::CIFactory::createCI(): cannot extract standard library include paths!
Invoking:
    echo | LC_ALL=C clang++-mp-3.5 -pipe -Os -arch x86_64 -stdlib=libc++  -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -std=c++11 -DR__HAVE_CONFIG -fPIC -fvisibility-inlines-hidden -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -xc++ -E -v - 2>&1 >/dev/null | awk '/^#include </,/^End of search/{if (!/^#include </ && !/^End of search/){ print }}' | grep -E "(c|g)\+\+"
results in
with exit code 256
sh: clang++-mp-3.5: command not found
Warning in cling::CIFactory::createCI():
  Possible C++ standard library mismatch, compiled with _LIBCPP_VERSION v1101 but extraction of runtime standard library version failed.
Invoking:
    echo '#include <vector>' | clang++-mp-3.5 -pipe -Os -arch x86_64 -stdlib=libc++  -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -std=c++11 -DR__HAVE_CONFIG -fPIC -fvisibility-inlines-hidden -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -xc++ -dM -E - | grep 'define _LIBCPP_VERSION' | awk '{print $3}'
results in
sh: clang++-mp-3.5: command not found
with exit code 0
input_line_3:6:10: fatal error: 'string' file not found
#include <string>
         ^
lookup.type.by.name.file:1:1: error: unknown type name 'string'
string
^
In file included from input_line_4:1:
In file included from /opt/local/libexec/root6/etc/root/cling/Interpreter/DynamicLookupRuntimeUniverse.h:16:
In file included from /opt/local/libexec/root6/etc/root/cling/Interpreter/Interpreter.h:13:
/opt/local/libexec/root6/etc/root/cling/Interpreter/InvocationOptions.h:13:10: fatal error: 'string' file not found
#include <string>
         ^

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

Thread 1 (process 79962):
#0  0x00007fff832a5168 in wait4 ()
#1  0x00007fff840ff5f5 in system ()
#2  0x00000001076fb471 in TUnixSystem::StackTrace ()
#3  0x00000001076fe799 in TUnixSystem::DispatchSignals ()
#4  <signal handler called>
#5  0x0000000107cd9a67 in cling::EvaluateTSynthesizer::Initialize ()
#6  0x0000000107cd9fb5 in cling::EvaluateTSynthesizer::Transform ()
#7  0x0000000107d06453 in cling::TransactionTransformer::TransformTransaction ()
#8  0x0000000107ceebbd in cling::IncrementalParser::endTransaction ()
#9  0x0000000107cefefe in cling::IncrementalParser::Compile ()
#10 0x0000000107cf4bc7 in cling::Interpreter::declare ()
#11 0x0000000107c65291 in TClingCallbacks::TClingCallbacks ()
#12 0x0000000107c32def in TCling::TCling ()
#13 0x0000000107c2f95f in CreateInterpreter ()
#14 0x0000000107620535 in TROOT::InitInterpreter ()
#15 0x0000000107620431 in ROOT::GetROOT2 ()
#16 0x00000001075daec9 in TApplication::TApplication ()
#17 0x0000000107ae17ba in TRint::TRint ()
#18 0x0000000107ae22d4 in TRint::TRint ()
#19 0x0000000107561e11 in main ()
===========================================================


The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5  0x0000000107cd9a67 in cling::EvaluateTSynthesizer::Initialize ()
#6  0x0000000107cd9fb5 in cling::EvaluateTSynthesizer::Transform ()
#7  0x0000000107d06453 in cling::TransactionTransformer::TransformTransaction ()
#8  0x0000000107ceebbd in cling::IncrementalParser::endTransaction ()
#9  0x0000000107cefefe in cling::IncrementalParser::Compile ()
#10 0x0000000107cf4bc7 in cling::Interpreter::declare ()
#11 0x0000000107c65291 in TClingCallbacks::TClingCallbacks ()
#12 0x0000000107c32def in TCling::TCling ()
#13 0x0000000107c2f95f in CreateInterpreter ()
#14 0x0000000107620535 in TROOT::InitInterpreter ()
#15 0x0000000107620431 in ROOT::GetROOT2 ()
#16 0x00000001075daec9 in TApplication::TApplication ()
#17 0x0000000107ae17ba in TRint::TRint ()
#18 0x0000000107ae22d4 in TRint::TRint ()
#19 0x0000000107561e11 in main ()
===========================================================

But there are a bunch of issues that I don't quite understand:

• (something was probably awfully wrong on this old laptop – maybe low disk space, web browser using all resources, slow processor etc., but) ROOT spent 3 hours compiling cling: why doesn't it use that built-in clang/cling compiler? Why does it struggle with the system compiler then? Should we open a ticket for that?
• Are you aware that currently ROOT would use, say, macports-clang-3.4 (on anything else but 10.9) without declaring a runtime dependency on that compiler? You only declare a dependency if user asks for it via +clang34, but not when that compiler is automatically selected.
• Assuming that ROOT gets compiled with clang-3.5. Would it have to be recompiled when clang-3.5 gets an update?

[cjones051073 (Chris Jones)]

But there are a bunch of issues that I don't quite understand:

• (something was probably awfully wrong on this old laptop – maybe low disk space, web browser using all resources, slow processor etc., but) ROOT spent 3 hours compiling cling: why doesn't it use that built-in clang/cling compiler? Why does it struggle with the system compiler then? Should we open a ticket for that?

ROOT only uses the in-built clang library for its cling interpreter. For real compilation tasks, it still uses the compiler that was used to build it itself.

• Are you aware that currently ROOT would use, say, macports-clang-3.4 (on anything else but 10.9) without declaring a runtime dependency on that compiler? You only declare a dependency if user asks for it via +clang34, but not when that compiler is automatically selected.

Ah no, thus is a nuance I had to appreciated. Is there anyway to enforce this, i.e. so whatever compiler is picked, following the fallback/blacklist rules, is then declared as a *runtime* dependency, not just a build time one ?

• Assuming that ROOT gets compiled with clang-3.5. Would it have to be recompiled when clang-3.5 gets an update?

Like any other dependency, that would depend on the update. But, for minor revisions within the same clang X.Y series, I would hope they would be ABI compatible, and thus no rebuild is needed.

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Yes, but the variants set configure.compiler, so the variants select the used compiler. We should try to avoid doing that as much as possible as it's a nightmare to maintain. If you intend to select the compiler used by root, that's fine, but don't set configure.compiler in that case.

Sorry, I must be missing something. What other method is there of selecting the compiler to use other than setting configure.compiler ? I thought that was the correct way to do it...

The preferred way is to use the blacklist mechanism. configure.compiler overrides all of that.

Replying to jonesc@…:

But there are a bunch of issues that I don't quite understand:

• (something was probably awfully wrong on this old laptop – maybe low disk space, web browser using all resources, slow processor etc., but) ROOT spent 3 hours compiling cling: why doesn't it use that built-in clang/cling compiler? Why does it struggle with the system compiler then? Should we open a ticket for that?

ROOT only uses the in-built clang library for its cling interpreter. For real compilation tasks, it still uses the compiler that was used to build it itself.

Earlier, someone gave the impression that the compiler used to build root was not necessarily the same as the compiler that it uses. So... that's not the case then? That's quite unfortunate.

• Are you aware that currently ROOT would use, say, macports-clang-3.4 (on anything else but 10.9) without declaring a runtime dependency on that compiler? You only declare a dependency if user asks for it via +clang34, but not when that compiler is automatically selected.

Ah no, thus is a nuance I had to appreciated. Is there anyway to enforce this, i.e. so whatever compiler is picked, following the fallback/blacklist rules, is then declared as a *runtime* dependency, not just a build time one ?

Not that I'm aware of. This is not really a valid case and represents a bug in root itself. The project (upstream) should make the distinction between the toolchain used to build it and the toolchain it uses. Without such a distinction, cross compilation is utterly impossible.

• Assuming that ROOT gets compiled with clang-3.5. Would it have to be recompiled when clang-3.5 gets an update?

Like any other dependency, that would depend on the update. But, for minor revisions within the same clang X.Y series, I would hope they would be ABI compatible, and thus no rebuild is needed.

Ok... yet another inconsistence. If you care about ABI, you should have a depends_lib rather than a depends_run. Are you executing something (depends_run), or linking something (depends_lib)?

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Replying to jonesc@…:

Yes, but the variants set configure.compiler, so the variants select the used compiler. We should try to avoid doing that as much as possible as it's a nightmare to maintain. If you intend to select the compiler used by root, that's fine, but don't set configure.compiler in that case.

Sorry, I must be missing something. What other method is there of selecting the compiler to use other than setting configure.compiler ? I thought that was the correct way to do it...

The preferred way is to use the blacklist mechanism. configure.compiler overrides all of that.

Seems a little indirect, when I know specifically which compiler we want, to have to try and blacklist everything else, and hope we end up with that one. Surely its better to just pick it...

Replying to jonesc@…:

But there are a bunch of issues that I don't quite understand:

• (something was probably awfully wrong on this old laptop – maybe low disk space, web browser using all resources, slow processor etc., but) ROOT spent 3 hours compiling cling: why doesn't it use that built-in clang/cling compiler? Why does it struggle with the system compiler then? Should we open a ticket for that?

ROOT only uses the in-built clang library for its cling interpreter. For real compilation tasks, it still uses the compiler that was used to build it itself.

Earlier, someone gave the impression that the compiler used to build root was not necessarily the same as the compiler that it uses. So... that's not the case then? That's quite unfortunate.

The situation is a little complicated...

ROOT5 - ROOT uses its own home baked interpreter (CINT) nothing to do with any real compiler. Whenever the user requests 'real' compilation, ROOT always uses the compiler that was used to build itself, in order to guarantee compatibility. This is by design, not a bug.

ROOT6 - ROOT has dropped CINT in favour of cling, which is a new interpreter based on clang. In order to do this, root builds its own internal clang library. However, for 'real' compilation tasks it still uses the same compiler as used to build itself. Again, by design, not a bug.

• Are you aware that currently ROOT would use, say, macports-clang-3.4 (on anything else but 10.9) without declaring a runtime dependency on that compiler? You only declare a dependency if user asks for it via +clang34, but not when that compiler is automatically selected.

Ah no, thus is a nuance I had to appreciated. Is there anyway to enforce this, i.e. so whatever compiler is picked, following the fallback/blacklist rules, is then declared as a *runtime* dependency, not just a build time one ?

Not that I'm aware of. This is not really a valid case and represents a bug in root itself. The project (upstream) should make the distinction between the toolchain used to build it and the toolchain it uses. Without such a distinction, cross compilation is utterly impossible.

I disagree. Its not a bug in ROOT but part of its design.

• Assuming that ROOT gets compiled with clang-3.5. Would it have to be recompiled when clang-3.5 gets an update?

Like any other dependency, that would depend on the update. But, for minor revisions within the same clang X.Y series, I would hope they would be ABI compatible, and thus no rebuild is needed.

Ok... yet another inconsistence. If you care about ABI, you should have a depends_lib rather than a depends_run. Are you executing something (depends_run), or linking something (depends_lib)?

Both. ROOT can either be used interactively, or third party application can just build and link against its own libraries.

I guess depends_lib encompasses depends_run ? Or do we have to do both...

Chris

[mojca (Mojca Miklavec)]

I think the question was whether root6 links against some library from clang-3.5 (not whether third-party programs link against root6). My blind guess is that all ROOT does is remember the compiler and compiler flags. But I might be wrong.

At least otool -L root doesn't show any links to clang.

ROOT6 - ROOT has dropped CINT in favour of cling, which is a new interpreted based on clang. In order to do this, root builds its own internal clang library. However, for 'real' compilation tasks it still uses the same compiler as used to build itself.

But then after uninstalling the compiler root should only fail when I would use it as compiler, not when I just run it (which should run cling if I understand correctly?).

Chris, the Portfile could probably always query the value of configure.compiler and set the runtime dependencies and port variants accordingly?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Replying to jeremyhu@…:

Replying to jonesc@…:

Yes, but the variants set configure.compiler, so the variants select the used compiler. We should try to avoid doing that as much as possible as it's a nightmare to maintain. If you intend to select the compiler used by root, that's fine, but don't set configure.compiler in that case.

Sorry, I must be missing something. What other method is there of selecting the compiler to use other than setting configure.compiler ? I thought that was the correct way to do it...

The preferred way is to use the blacklist mechanism. configure.compiler overrides all of that.

Seems a little indirect, when I know specifically which compiler we want, to have to try and blacklist everything else, and hope we end up with that one. Surely its better to just pick it...

No. You're looking at it the wrong way. It is not the port's responsibility to set the compiler. It is the ports responsibility to state which compilers wont work, and it is base and the user that choose the compiler.

ROOT6 - ROOT has dropped CINT in favour of cling, which is a new interpreter based on clang. In order to do this, root builds its own internal clang library. However, for 'real' compilation tasks it still uses the same compiler as used to build itself. Again, by design, not a bug.

No, that is definitely, 100% a bug. If I am building on Linux and deploying to FreeBSD, this will obviously not work. That design decision causes cross compilation to outright fail and is misdesigned.

Not that I'm aware of. This is not really a valid case and represents a bug in root itself. The project (upstream) should make the distinction between the toolchain used to build it and the toolchain it uses. Without such a distinction, cross compilation is utterly impossible.

I disagree. Its not a bug in ROOT but part of its design.

No, it is definitely a bug in the build system.

Ok... yet another inconsistence. If you care about ABI, you should have a depends_lib rather than a depends_run. Are you executing something (depends_run), or linking something (depends_lib)?

Both. ROOT can either be used interactively, or third party application can just build and link against its own libraries.

I guess depends_lib encompasses depends_run ? Or do we have to do both...

depends_run is not needed if you depends_lib.

[cjones051073 (Chris Jones)]

ROOT6 - ROOT has dropped CINT in favour of cling, which is a new interpreter based on clang. In order to do this, root builds its own internal clang library. However, for 'real' compilation tasks it still uses the same compiler as used to build itself. Again, by design, not a bug.

No, that is definitely, 100% a bug. If I am building on Linux and deploying to FreeBSD, this will obviously not work. That design decision causes cross compilation to outright fail and is misdesigned.

You are assuming cross compilation is something that makes sense for ROOT, and that upstream support.... It isn't on both counts.

Not that I'm aware of. This is not really a valid case and represents a bug in root itself. The project (upstream) should make the distinction between the toolchain used to build it and the toolchain it uses. Without such a distinction, cross compilation is utterly impossible.

I disagree. Its not a bug in ROOT but part of its design.

No, it is definitely a bug in the build system.

Going to have to agree to disagree here...

[mojca (Mojca Miklavec)]

Luckily I don't know enough about ROOT to be able to judge with whom I disagree. Jeremy's opinion makes more sense to me (but then again I don't know enough about the internals to understand why Chris might be right ;)

This disagreement slightly reminds me on MacPorts insisting to always use the same compiler (and trying to avoid using gcc and the non-native libstdc++/libc++), saying that all the deviations from that are unsupported ... and users or developers trying to claim that their software must be compiled with X for reason Y (my favourite being a developer hardcoding gcc and saying that I need to make a symlink like $[SOME]PATH/gcc -> /opt/local/bin/gcc-mp-4.8 if I really want to use another version of gcc; that no other compiler but gcc is supported). For MacPorts developers it is hard to explain why compiling with gcc is not recommended. And maybe in a similar way it's difficult for ROOT developers to explain why they are not willing to support ROOT being compiled with gcc, followed by trying to use clang-3.5 for real work. I strongly suspect that ROOT insisting on using exactly the same compiler has pretty much the same reasons as MacPorts trying to use the same compiler for building all ports.

But something makes me believe that a single, built-in compiler, could probably be used for everything if set up properly.

I opened a ticket to ask about the possibility for implementing that. Let's see what they respond:

• ​https://sft.its.cern.ch/jira/browse/ROOT-6373

[cjones051073 (Chris Jones)]

Its a choice the ROOT devs have made to minimise the problems they have to deal with. Yes, in theory some mixing of compilers could work, but its not absolute, in that some combinations will have problems. For this reason an enforcement of the same compiler is made. In practise this is not a constraint within the scientific world where ROOT is primarily used, as it is very much common practise to enforce a single compiler within a given suite of experiment software. Cross compilation is not a requirement.

So its not about being right or wrong. Its a choice that has been made for various reasons. Whether or not you agree with them or not is up to you.

Anyway, can I suggest we stop discussing the rights or wrongs of ROOTs build system, as that not really the issue at hand. It is what it is. Going back the the 10.6 compilation failures, could you check to see if the livcxx port is actually being used in the buildbot compilation that fails ?

Chris

[mojca (Mojca Miklavec)]

The log from the buildbot says the following:

--->  Activating libcxxabi @183506_1
DEBUG: Using /usr/bin/tar
DEBUG: Using /usr/bin/bzip2
x ./
x ./+COMMENT
x ./+CONTENTS
x ./+DESC
x ./+PORTFILE
x ./+STATE
x ./opt/
x ./opt/local/
x ./opt/local/var/
x ./opt/local/var/host/
x ./opt/local/var/host/libcxxabi-183506-1/
x ./opt/local/var/host/libcxxabi-183506-1/usr/
x ./opt/local/var/host/libcxxabi-183506-1/usr/include/
x ./opt/local/var/host/libcxxabi-183506-1/usr/lib/
x ./opt/local/var/host/libcxxabi-183506-1/usr/lib/libc++abi.dylib
x ./opt/local/var/host/libcxxabi-183506-1/usr/include/cxa_demangle.h
x ./opt/local/var/host/libcxxabi-183506-1/usr/include/cxxabi.h
--->  Activating libcxx @183506_1
DEBUG: Using /usr/bin/tar
DEBUG: Using /usr/bin/bzip2
x ./
x ./+COMMENT
x ./+CONTENTS
x ./+DESC
x ./+PORTFILE
x ./+STATE
x ./opt/
x ./opt/local/
x ./opt/local/var/
x ./opt/local/var/host/
x ./opt/local/var/host/libcxx-183506-1/
x ./opt/local/var/host/libcxx-183506-1/usr/
x ./opt/local/var/host/libcxx-183506-1/usr/lib/
x ./opt/local/var/host/libcxx-183506-1/usr/lib/libc++.1.dylib
x ./opt/local/var/host/libcxx-183506-1/usr/lib/libc++.dylib

There might be a problem with location of the library (or the lack of options specifying where to look for it).

[mojca (Mojca Miklavec)]

Chris, the following works for me to set the variant:

# forgot if it should be eq or ==
if { ${configure.compiler} eq "macports-clang-3.4" } {
    default_variants-append +clang34
}

[cjones051073 (Chris Jones)]

Replying to mojca@…:

The log from the buildbot says the following:

--->  Activating libcxxabi @183506_1
DEBUG: Using /usr/bin/tar
DEBUG: Using /usr/bin/bzip2
x ./
x ./+COMMENT
x ./+CONTENTS
x ./+DESC
x ./+PORTFILE
x ./+STATE
x ./opt/
x ./opt/local/
x ./opt/local/var/
x ./opt/local/var/host/
x ./opt/local/var/host/libcxxabi-183506-1/
x ./opt/local/var/host/libcxxabi-183506-1/usr/
x ./opt/local/var/host/libcxxabi-183506-1/usr/include/
x ./opt/local/var/host/libcxxabi-183506-1/usr/lib/
x ./opt/local/var/host/libcxxabi-183506-1/usr/lib/libc++abi.dylib
x ./opt/local/var/host/libcxxabi-183506-1/usr/include/cxa_demangle.h
x ./opt/local/var/host/libcxxabi-183506-1/usr/include/cxxabi.h
--->  Activating libcxx @183506_1
DEBUG: Using /usr/bin/tar
DEBUG: Using /usr/bin/bzip2
x ./
x ./+COMMENT
x ./+CONTENTS
x ./+DESC
x ./+PORTFILE
x ./+STATE
x ./opt/
x ./opt/local/
x ./opt/local/var/
x ./opt/local/var/host/
x ./opt/local/var/host/libcxx-183506-1/
x ./opt/local/var/host/libcxx-183506-1/usr/
x ./opt/local/var/host/libcxx-183506-1/usr/lib/
x ./opt/local/var/host/libcxx-183506-1/usr/lib/libc++.1.dylib
x ./opt/local/var/host/libcxx-183506-1/usr/lib/libc++.dylib

There might be a problem with location of the library (or the lack of options specifying where to look for it).

The above is the content of the port, but if I am reading the Portfile for livcxx correctly the library should get sum linked into the system place under /usr/lib/ ... Can you see any messages in the log that confirm this is happening properly ?

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Chris, the following work for me to set the variant:

# forgot if it should be eq or ==
if { ${configure.compiler} eq "macports-clang-3.4" } {
    default_variants-append +clang34
}

Yeah, I guess that would cover the cases where the MP clang compilers are picked by the fallback/blacklist system. Please feel free to add these to the port, for each clang variant.

Chris

[mojca (Mojca Miklavec)]

The above is the content of the port, but if I am reading the Portfile for libcxx correctly the library should get sym linked into the system place under /usr/lib/ ... Can you see any messages in the log that confirm this is happening properly ?

No. The post-activate phase should run

    post-activate {
        system "ditto ${root_path} /"
    }

but that probably isn't logged.

---

I can add the variants, but I suspect that we will also add some other changes (10.6 or anything else), so maybe I can commit everything in a batch to avoid multiple compilations.

I thought you wanted to make a "for loop" over compilers ;) and we probably also need to add something like that to root5.

---

Unrelated: in case that you have some experience with Cocoa, are you able to figure out how to enable UTF-8-encoded strings in function AddContributorsInfo in rootx/src/rootxx-cocoa.mm? The wrong text is displayed at startup or if you click on "Help->About" in TBrowser. I'm willing to play with it a bit, but I need to experiment on a faster machine, not here.

    std::list<std::string> contributors;
    ...
    std::list<std::string>::const_iterator it = contributors.begin(),
                                          end = contributors.end(), begin = contributors.begin();
    for (; it != end; ++it) {
        //Quite ugly :( NSString/NSAttributedString ARE ugly.
        NSString * const nsFromC = [NSString stringWithFormat : it != begin ? @", %s" : @"%s", it->c_str()];
        newString.Reset([[NSAttributedString alloc] initWithString : nsFromC]);

        if (newString.Get()) {
            [textToScroll appendAttributedString : newString.Get()];
        }
    }

Somewhere an encoding option is missing. This needs to be reported upstream, but they are aware of it (TODO: problems with non-ascii)

[jfcaron3]

By the way, I was having compiling ROOT myself on OSX 10.9, but as I use MacPorts for other reasons, I also tried installing the root6 port. It builts ok, but I immediately get a seg fault if I actually try to run root or root6. See here: ​http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=18143&p=77299#p77299

Should I open a new ticket?

[mojca (Mojca Miklavec)]

Feel free to open a new ticket, even though I strongly suspect that there might be something strange on your system (maybe you installed some libraries yoursel and ROOT from MacPorts is picking up those). Does ROOT crash immediately after you run it? If that is so, it will be a bit difficult to reproduce because at least starting ROOT works for us and some additional input from you might be needed. When you open the ticket, please run "otool -L <all bin and dylib files from ROOT>" and check if any of the reported files points to strange locations (other than ${prefix}, /usr/lib/lib*.dylib and Apple Frameworks).

Btw: the ROOT developers keep getting the impression that MacPorts is hopelessly broken if they hear that word too often in bug reports. For crashes at startup of MacPorts programs it might be better to ask the MacPorts gurus directly. (You can also try IRC.)

[cjones051073 (Chris Jones)]

I agree with Mojca. This is something specific to your setup, as root6 runs fine for me on my OSX10.9 systems. Please provide the requested information.

[mojca (Mojca Miklavec)]

• Snow Leopard problems: #44062
• crashing with multithreading turned on: #43989