Fails to build: conflict with C++11 standards?

[Generic User (don't modify these fields)]

Hello, I am trying to build Sherpa 2.0 on OS X 10.9, where they have replaced their llvm-gcc hybrid with a standalone llvm. It seems clang is a bit more fussy about standards than gcc.

In MODEL/Main/SM_U1_B.C there are the statements:

Complex entry=Complex(0.,0.); for (int k=0;k<3;++k) entry += Mix[i][k]*Mixconj[k][j]; if (ATOOLS::dabs(entry.real())<1.e-12) entry.real() = 0.; if (ATOOLS::dabs(entry.imag())<1.e-12) entry.imag() = 0.; if (ATOOLS::dabs(1.-entry.real())<1.e-12) entry.real() = 1.; if (ATOOLS::dabs(1.-entry.imag())<1.e-12) entry.imag() = 1.; msg_Out()<<std::setw(os)<<entry;

But the C++11 standard says that the methods complex::real() and complex::imag() return values not references, and cannot be assigned as lvalues. There is a discussion of including the setters in gcc at ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013

I'm not sure how you want to handle this. I thought I should raise this though.

David

[Frank Siegert]

Hi David,

thanks for the report! Could you test on your system whether a simple replacement like:

Index: MODEL/Main/SM_U1_B.C
===================================================================
--- MODEL/Main/SM_U1_B.C	(revision 22732)
+++ MODEL/Main/SM_U1_B.C	(working copy)
@@ -177,10 +177,10 @@
       for (int j=0;j<3;++j) {
 	Complex entry=Complex(0.,0.);
 	for (int k=0;k<3;++k) entry += Mix[i][k]*Mixconj[k][j];
-	if (ATOOLS::dabs(entry.real())<1.e-12) entry.real() = 0.;
-	if (ATOOLS::dabs(entry.imag())<1.e-12) entry.imag() = 0.;
-	if (ATOOLS::dabs(1.-entry.real())<1.e-12) entry.real() = 1.;
-	if (ATOOLS::dabs(1.-entry.imag())<1.e-12) entry.imag() = 1.;
+	if (ATOOLS::dabs(entry.real())<1.e-12) entry = Complex(0., entry.imag());
+	if (ATOOLS::dabs(entry.imag())<1.e-12) entry = Complex(entry.real(), 0.);
+	if (ATOOLS::dabs(1.-entry.real())<1.e-12) entry = Complex(1., entry.imag());
+	if (ATOOLS::dabs(1.-entry.imag())<1.e-12) entry = Complex(entry.real(), 1.);
 	msg_Out()<<std::setw(os)<<entry;
       }
       msg_Out()<<"\n";

fixes this, or whether there are any more occurences of this issue?

Cheers, Frank

[David.Hall@physics.ox.ac.uk]

Hi Frank,

Yes, that was the fix I tried also, and it works fine. Unfortunately I then experience problems later in the build to do with maps. I'm still not sure what the problem there is though.

Cheers, David

[Frank Siegert]

Ok, thanks for the confirmation. If you make any progress on the other issues (and also if not), could you post their details here? I don't have an OS X 10.9 machine to test with myself. I would then put the fixes into the rel-2-0-0 SVN branch for the benefit of other MacOS users running into the same issues.

Cheers, Frank

[David.Hall@physics.ox.ac.uk]

Hi Frank,

I got it to compile in the end. I'll test it in a minute. But the required changes to achieve compilation are in AHADIC++/Tools/Transitions.H

Both the following predicates needed to become const:

Flavour_Sorting_Mass::operator() 
Flavour_Pair_Sorting_Mass::operator()

I guess you will be able to say whether this is okay or not? Normally predicates aren't supposed to change anything...

Cheers, David

[David.Hall@physics.ox.ac.uk]

Hi Frank,

Ok, so Sherpa is running ok and seems to link at runtime, etc etc. It does the integration step.

However, it fails at the event generation step. The output is not particularly helpful, so I don't really have much to go on.

----------------------------------------------------------
-- SHERPA generates events with the following structure --
----------------------------------------------------------
Perturbative       : Signal_Processes
Perturbative       : Hard_Decays
Perturbative       : Jet_Evolution:CSS
Perturbative       : Lepton_FS_QED_Corrections:Photons
Perturbative       : Multiple_Interactions:None
Perturbative       : Minimum_Bias:Off
Hadronization      : Beam_Remnants
Hadronization      : Hadronization:Ahadic
Hadronization      : Hadron_Decays
---------------------------------------------------------
  Event 2 ( 0s elapsed / 0s left ) -> ETA: Fri Nov 01 17:10
Exception_Handler::SignalHandler: Signal (11) caught.
   Cannot continue.

If you have any ideas, I can try them out. But I'm afraid I won't be able to do much more on this by myself. I built Sherpa without any external dependencies.

Cheers, David

[Frank Siegert]

Hi David,

thanks for the follow-up! One thing that would already help a great deal is if you could attach the debugging output from the event generation up to the crash. You can get that by simply running with the additional command-line option EVT_OUTPUT=15 (and piping the output to a file).

Cheers, Frank

[David.Hall@physics.ox.ac.uk]

Hi Frank,

The log file is too big for trac so I sent it in an email to you.

Cheers, David

[Frank Siegert]

Thanks! I've temporarily uploaded it to ​http://fsiegert.web.cern.ch/fsiegert/tmp/dhall.log such that the other Sherpa authors can also take a look.

FrankK, it seems to crash in the 9th event in Ahadic, do you see anything weird going on before the crash?

Cheers, Frank

[Bob Holdom <bob.holdom@utoronto.ca>]

I have Sherpa 2.0.0 working fine on Mac OS 10.9 after compiling with the following flags.

export CFLAGS='-g -O2 -mmacosx-version-min=10.8 -stdlib=libstdc++ -lstdc++' export CXXFLAGS='-g -O2 -mmacosx-version-min=10.8 -stdlib=libstdc++ -lstdc++' export LDFLAGS='-mmacosx-version-min=10.8 -stdlib=libstdc++' export LIBS=-lstdc++

The resulting warning clang: warning: -Z-reserved-lib-stdc++: 'linker' input unused doesn't seem to hurt.

I couldn't get a scons compile to work in one of the Examples though.

[Frank Siegert]

Thanks for the comment, Bob.

David, we have also had other reports of successful running on Mac OS 10.9, and also on Linux with clang. Maybe you could also try with the flags provided by Bob (although I'm not aware of other users having used them)?

[David.Hall@physics.ox.ac.uk]

But the flags here are selecting the libstdc++ library, rather than the Mavericks-standard libc++ library. Since everything else will be linked to libc++, I think it'd be a bad idea to link Sherpa to libstdc++.

I guess this means that there wasn't anything useful in the log file then?

[Frank Siegert]

I don't know the C++ library situation on Mac OS, so I'll let somebody else comment.

As for the log file, it seems to look normal right up to the crash.

[Frank Siegert]

I'm closing this fails-to-build report, which should be resolved with recent Sherpa releases. Unfortunately it doesn't seem like anybody was able to reproduce/debug the second Mac OS runtime/linking issue, but maybe it's working with more recent Sherpa releases? As I said, we have had user reports of Sherpa 2.1.x working fine in Mac OS 10.9 (even via homebrew-hep), so if this problem persists please do post a (separate) bug report with the details, and I'll try to add somebody who had success.

Cheers, Frank