[Rivet] Fwd: Rivet on MAC

[David Grellscheid]

Hi,

We've got Rivet on IPPP's Mac. That's Lion, so CC should be clang. Let 
me confirm, though.

   David


On 01/02/12 17:22, Andy Buckley wrote:
> James reminded me last night that some time ago I tried to get Rivet to
> build with clang(++) on Ubuntu. It took some initial fiddling to get
> clang to recognise the position of the std libraries, and when it did
> find them my recollection is that it produced a lot of warnings: it
> looks like a *very* strict compiler (hmm, and they're using this to
> rewrite ROOT's CINT parser? Could be interesting...)
>
> If clang has become the default compiler on Macs, I presume that they've
> sorted out the std library issues, but the strictness could still be an
> issue for Rivet and the libraries it depends on. Maybe there is a flag
> to tell it to be less obsessive, at least for now.
>
> Andy
>
>
> On 30/01/12 18:33, James Monk wrote:
>> I haven't read all of that thoroughly, but I notice he mentions clang.
>> My understanding is that clang is the default compiler under 10.7. In
>> principle this is fine and should work with a GNU tool chain and be
>> basically swappable for gcc, but I've never used 10.7 myself (other
>> than the brief period when my new laptop came installed with it), so I
>> don't know if that's actually the case (in fact this was one of the
>> reasons I haven't "upgraded" to 10.7).
>>
>> So it isn't that Rivet "tries to compile itself... with clang," it
>> doesn't have much of a choice about that. The fact that autotools has
>> obviously detected clang and tried to run it is actually encouraging.
>> I'd guess things might go a bit wrong if it (or the user, via
>> symlinks) tries to mix together compilers in the build, but I don't
>> really know - somewhere back in London I have a 10.7 boot disk from
>> which I could try all of this out, but right now I'm a bit busy with
>> MC12 ;)
>>
>> cheers,
>>
>> James
>>
>>
>> On 30 Jan 2012, at 15:57, David Grellscheid wrote:
>>
>>> Just found this... any input?
>>>
>>> David
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Rivet on MAC
>>> Date: Sun, 15 Jan 2012 22:40:08 +0100
>>> From: Juergen Reuter<juergen.reuter at desy.de>
>>> To: David Grellscheid<david.grellscheid at durham.ac.uk>,
>>> andy.buckley at ed.ac.uk
>>> CC: Daniel Wiesler<daniel.wiesler at desy.de>, Jürgen
>>> Reuter<juergen.reuter at desy.de>
>>>
>>> Hi David,
>>> I think you already have some tickets concerning Rivet under MAC OS X,
>>> but nevertheless I summarize
>>> my problems here:
>>> *****
>>> 1) even when configured with --without-yaml_cpp, as soon as the yaml_cpp
>>> lib and headers are installed,
>>> I get this error in AnalysisInfo. Uninstalling yaml_cpp (v0.2.6) solves
>>> the problem.
>>> CXX libRivetCore_la-AnalysisInfo.lo
>>> AnalysisInfo.cc: In static member function ‘static Rivet::AnalysisInfo*
>>> Rivet::AnalysisInfo::make(const string&)’:
>>> AnalysisInfo.cc:67:28: error: ‘const class YAML::Node’ has no member
>>> named ‘GetType’
>>> AnalysisInfo.cc:67:41: error: ‘CT_SCALAR’ is not a member of ‘YAML’
>>> AnalysisInfo.cc:68:28: error: ‘const class YAML::Node’ has no member
>>> named ‘GetType’
>>> AnalysisInfo.cc:68:41: error: ‘CT_SCALAR’ is not a member of ‘YAML’
>>> AnalysisInfo.cc:77:25: error: ‘const class YAML::Node’ has no member
>>> named ‘GetType’
>>> AnalysisInfo.cc:77:38: error: ‘CT_SCALAR’ is not a member of ‘YAML’
>>> AnalysisInfo.cc:78:25: error: ‘const class YAML::Node’ has no member
>>> named ‘GetType’
>>> AnalysisInfo.cc:78:38: error: ‘CT_SCALAR’ is not a member of ‘YAML’
>>> AnalysisInfo.cc:94:21: error: ‘const class YAML::Node’ has no member
>>> named ‘GetType’
>>> AnalysisInfo.cc:94:34: error: ‘CT_SCALAR’ is not a member of ‘YAML’
>>> AnalysisInfo.cc:99:28: error: ‘const class YAML::Node’ has no member
>>> named ‘GetType’
>>> AnalysisInfo.cc:99:41: error: ‘CT_SEQUENCE’ is not a member of ‘YAML’
>>> ../../include/Rivet/Math/MathHeader.hh: At global scope:
>>> ../../include/Rivet/Math/MathHeader.hh:42:16: warning: ‘Rivet::MAXINT’
>>> defined but not used [-Wunused-variable]
>>> *****
>>> 2) When compiling the OPAL2004 Analysis I get the following error:
>>> CXX OPAL_2004_S6132243.lo
>>> OPAL_2004_S6132243.cc: In member function ‘virtual void
>>> Rivet::OPAL_2004_S6132243::analyze(const Rivet::Event&)’:
>>> OPAL_2004_S6132243.cc:167:25: error: ‘isnan’ was not declared in this
>>> scope
>>> OPAL_2004_S6132243.cc:167:25: note: suggested alternatives:
>>> /usr/local/lib/gcc/x86_64-apple-darwin11.2.0/4.6.2/../../../../include/c++/4.6.2/cmath:768:5:
>>>
>>> note: ‘std::isnan’
>>> /opt/local/include/boost/math/special_functions/fpclassify.hpp:515:25:
>>> note: ‘boost::math::isnan’
>>> ../../include/Rivet/Math/MathHeader.hh: At global scope:
>>> ../../include/Rivet/Math/MathHeader.hh:42:16: warning: ‘Rivet::MAXINT’
>>> defined but not used [-Wunused-variable]
>>>
>>> There is still a TODO in your code ;) but commenting out the isnan catch
>>> solves the problem.
>>> This is funny because the file cmath which contains the isnan is
>>> identical to the one on a Linux machine (same gcc) where
>>> I do not have a problem.
>>> *****
>>> 3) Next thing is that Rivet tries to compile itself in the (almost)
>>> final step with clang(++) under MAC which utterly
>>> (cf. extra file attached). This seems to be hard-coded. If I set a sym
>>> link forcing clang to be gcc and clang++ to be
>>> g++ it works.
>>> *****
>>> 4) There is also a problem in doc:
>>> LD_LIBRARY_PATH=../src/.libs:/usr/local/lib:/usr/local/lib: \
>>> DYLD_LIBRARY_PATH=../src/.libs:/usr/local/lib:/usr/local/lib: \
>>> RIVET_INFO_PATH=../data/anainfo \
>>> /opt/local/bin/python mk-analysis-latex
>>> Traceback (most recent call last):
>>> File "mk-analysis-latex", line 43, in<module>
>>> import rivet
>>> File
>>> "/usr/local/packages/Rivet-1.7.0/pyext/build/lib.macosx-10.7-x86_64-2.7/rivet/__init__.py",
>>>
>>> line 16, in<module>
>>> from rivetwrap import *
>>> File
>>> "/usr/local/packages/Rivet-1.7.0/pyext/build/lib.macosx-10.7-x86_64-2.7/rivet/rivetwrap.py",
>>>
>>> line 26, in<module>
>>> _rivetwrap = swig_import_helper()
>>> File
>>> "/usr/local/packages/Rivet-1.7.0/pyext/build/lib.macosx-10.7-x86_64-2.7/rivet/rivetwrap.py",
>>>
>>> line 22, in swig_import_helper
>>> _mod = imp.load_module('_rivetwrap', fp, pathname, description)
>>> ImportError:
>>> dlopen(/usr/local/packages/Rivet-1.7.0/pyext/build/lib.macosx-10.7-x86_64-2.7/rivet/_rivetwrap.so,
>>>
>>> 10): Library not loaded: /usr/local/lib/libyaml-cpp.0.dylib
>>> Referenced from:
>>> /usr/local/packages/Rivet-1.7.0/src/.libs/libRivet.10.dylib
>>> Reason: image not found
>>>
>>> Due to some reason, Rivet/dlopen believes to depend on some libraries in
>>> /usr/local which do not exist!? This only happens for
>>> libyaml_cpp. Problem here is that the package to be installed on MAC OS
>>> X Lion only contains the static build, but Rivet demands
>>> for the dynamic build. I solved the problem by manually copying
>>> src/Tools/yaml-cpp/.libs/libyaml-cpp.0.dylib to $(prefix)/lib.
>>>
>>> Then Rivet compiled (!).
>>> But running it immediatly gave a Python runtime error, I'm using Python
>>> 2.7. :(((
>>> I attached the crash report.
>>> So I guess, it runs on Scientific Linux, but on my laptop is not usable.
>>> Cheers,
>>> JRR
>>>
>>> --
>>> -------------------------------------
>>> Juergen Reuter
>>> *****
>>> DESY Theory Group
>>> Notkestrasse 85
>>> D-22603 Hamburg
>>> Phone: +49 (0)40 8998-3895
>>> Fax : +49 (0)40 8998-2777
>>>
>>> *****
>>> Skype: jr_reuter
>>> -------------------------------------
>>>
>>>
>>> <rivet_clang.txt><rivet_crash.txt><config.log>_______________________________________________
>>>
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> http://www.hepforge.org/lists/listinfo/rivet
>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> http://www.hepforge.org/lists/listinfo/rivet
>>
>
>