I’m having a problem building the git head of ROOT on OSX 10.8.5 with C++11 support. The problem seems to occur when building the RooFit module. The rootcling_tmp program generates dictionary code (file attached) which contains (among some other problematic statements):
The problem is that on OSX, libc++ is not the GNU library so the namespace __gnu_cxx is undefined (and indeed the way that iterators are implemented is probably different so a simple text replacement won’t work, and would simply be overwritten if the dictionary was regenerated anyway). I tried to work out why rootcling was generating this code and tracked it as far as TMetaUtils (e.g. in TMetaUtils::WriteClassInit), but then it goes deeper into cling and clang calls, so I though I might make faster progress by appealing for help here.
Is there any way to prevent rootcling from generating this code. Where is it even getting the __gnu_cxx namespace name from? Grepping the ROOT source tree doesn’t find any matching hard-coded strings that match precisely (although there are a few with “_gnu_cxx::hash”) so I’m guessing cling/clang must see a declaration or definition for __gnu_cxx::__normal_iterator which includes the namespace at some point earlier in the build. Any help would be very much appreciated.
Thanks for the quick reply. Unfortunately it didn’t work. Indeed, it looks to me like specifying “–enable-c++11” automatically enables the libc++11 flag in the configure script. I’m wondering whether some MacPorts gcc or llvm installation is getting in the way during the build. I’ve removed /opt/* from all the system paths and deactivated the gcc48 port, but it doesn’t seem to make any difference.
I also notice that when llvm/clang/cling are building, the _GNU_SOURCE macro is defined, so there might be a bug in that part of the build system. I’ll try to investigate, but in the meantime any other ideas would be helpful.
Turns out that my build also fails on RooFit, so I will take a closer look (so unless you need roofit, you can disable it for now and the build should succeed).
The problem is per se solved. (One does not need to generate the I/O for of vector of pair of iterator, so even-though the underlying problem is not yet solved, it is render moot for the moment by properly marking the member of that type as transient [it was a bug they were not]).
The build now works for me as well. It would be good to know if and when the underlying problem is ever solved. To be honest, I’m just curious to know what was causing it!
This is a configuration problem (using the g++ include file instead of the clang header file) during the run of rootcling. You can follow the resolution at https://sft.its.cern.ch/jira/browse/ROOT-5554.
It seems that fixing this problem may have introduced/resurrected another problem. Namely, some annoying link errors seem to have appeared in the interpreter. Things like:
[quote]ExecutionContext: use of undefined symbol ‘_ZN5cling20valuePrinterInternal13flushToStreamERN4llvm11raw_ostreamERKSs’!
ExecutionContext::executeFunction: symbol ‘_ZN5cling20valuePrinterInternal13flushToStreamERN4llvm11raw_ostreamERKSs’ unresolved while linking function ‘_Z15__cling_Un1Qu31v’![/quote]
A quick google search revealed that similar problems have apparently occurred before (sft.its.cern.ch/jira/browse/ROOT-5360). The issue has been marked as resolved but it’s not clear from the comments how this was achieved. What is the solution? Do I need to add a library load to my rootlogon or something?