Geant4: fails to link against CLHEP with clang 3.4

[graziosi.angelo@…]

Today:

$ sudo port selfupdate
[...]
$ sudo port outdated
The following installed ports are outdated:
clhep                          2.1.3.1_0 < 2.1.4.1_0
geant4.9.6                     4.9.6.p02_0 < 4.9.6.p02_1
sqlite3                        3.8.3.1_0 < 3.8.4.1_0

$ sudo port upgrade outdated
--->  Computing dependencies for clhep
--->  Fetching archive for clhep
--->  Attempting to fetch clhep-2.1.4.1_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/clhep
--->  Attempting to fetch clhep-2.1.4.1_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/clhep
--->  Attempting to fetch clhep-2.1.4.1_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/clhep
--->  Fetching distfiles for clhep
--->  Verifying checksums for clhep
--->  Extracting clhep
--->  Configuring clhep
--->  Building clhep
--->  Staging clhep into destroot
--->  Installing clhep @2.1.4.1_0
--->  Cleaning clhep
--->  Deactivating clhep @2.1.3.1_0
--->  Cleaning clhep
--->  Activating clhep @2.1.4.1_0
--->  Cleaning clhep
--->  Computing dependencies for sqlite3
--->  Fetching archive for sqlite3
--->  Attempting to fetch sqlite3-3.8.4.1_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/sqlite3
--->  Attempting to fetch sqlite3-3.8.4.1_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/sqlite3
--->  Attempting to fetch sqlite3-3.8.4.1_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/sqlite3
--->  Fetching distfiles for sqlite3
--->  Attempting to fetch sqlite-autoconf-3080401.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/sqlite3
--->  Verifying checksums for sqlite3
--->  Extracting sqlite3
--->  Applying patches to sqlite3
--->  Configuring sqlite3
--->  Building sqlite3
--->  Staging sqlite3 into destroot
--->  Installing sqlite3 @3.8.4.1_0
--->  Cleaning sqlite3
--->  Computing dependencies for sqlite3
--->  Deactivating sqlite3 @3.8.3.1_0
--->  Cleaning sqlite3
--->  Activating sqlite3 @3.8.4.1_0
--->  Cleaning sqlite3
--->  Computing dependencies for geant4.9.6
--->  Fetching archive for geant4.9.6
--->  Attempting to fetch geant4.9.6-4.9.6.p02_1+gdml+qt.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/geant4.9.6
--->  Attempting to fetch geant4.9.6-4.9.6.p02_1+gdml+qt.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/geant4.9.6
--->  Attempting to fetch geant4.9.6-4.9.6.p02_1+gdml+qt.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/geant4.9.6
--->  Fetching distfiles for geant4.9.6
--->  Verifying checksums for geant4.9.6
--->  Extracting geant4.9.6
--->  Applying patches to geant4.9.6
--->  Configuring geant4.9.6
--->  Building geant4.9.6
Error: org.macports.build for port geant4.9.6 returned: command execution failed
Please see the log file for port geant4.9.6 for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_geant4/geant4.9.6/main.log
Error: Unable to upgrade port: 1
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

So, clhep and sqlite were upgrade successfully but geant4 failed.

Here is on

OS X 10.9.2
Xcode 5.1 (5B130a)
Command Line Tools 5.1

$ clang -v
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

Ciao, Angelo.

[mojca (Mojca Miklavec)]

It looks like exactly the same problem as in #42841 (I suspected this would happen):

:info:build /usr/bin/clang++  -pipe -Os -I/opt/local/include -arch x86_64 -W -Wall -pedantic -Wno-non-virtual-dtor -Wno-long-long -Wwrite-strings -Wpointer-arith -Woverloaded-virtual -pipe -Qunused-arguments -std=c++98 -DNDEBUG -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o ../../outputs/library/Darwin-clang/libG4graphics_reps.dylib -install_name /opt/local/lib/Geant4/Geant4.9.6/libG4graphics_reps.dylib CMakeFiles/G4graphics_reps.dir/src/G4AttCheck.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttDef.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttDefStore.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttHolder.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttUtils.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Circle.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Colour.cc.o CMakeFiles/G4graphics_reps.dir/src/G4DimensionedTypeUtils.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBS.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBSbox.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBScylinder.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBShexahedron.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBStube.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBStubesector.cc.o CMakeFiles/G4graphics_reps.dir/src/G4PlacedPolyhedron.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Point3DList.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Polyhedron.cc.o CMakeFiles/G4graphics_reps.dir/src/G4PolyhedronArbitrary.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Polyline.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Polymarker.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Scale.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Square.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Text.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VGraphicsScene.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VMarker.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VVisManager.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VisAttributes.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VisExtent.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Visible.cc.o CMakeFiles/G4graphics_reps.dir/src/HepPolyhedron.cc.o ../../outputs/library/Darwin-clang/libG4global.dylib ../../outputs/library/Darwin-clang/libG4intercoms.dylib ../../outputs/library/Darwin-clang/libG4global.dylib /opt/local/lib/libCLHEP.dylib -Wl,-rpath,/opt/local/lib 
:info:build Undefined symbols for architecture x86_64:
:info:build   "HepGeom::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, HepGeom::BasicVector3D<double> const&)", referenced from:
:info:build       operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, G4Point3DList const&) in G4Point3DList.cc.o
:info:build       operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, G4VMarker const&) in G4VMarker.cc.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [outputs/library/Darwin-clang/libG4graphics_reps.dylib] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_geant4/geant4.9.6/work/build'
:info:build make[1]: *** [source/graphics_reps/CMakeFiles/G4graphics_reps.dir/all] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_geant4/geant4.9.6/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory 

Can you please try adding the same patch as in r117888 to the Geant4 port?

[graziosi.angelo@…]

Replying to mojca@…:

It looks like exactly the same problem as in #42841 (I suspected this would happen):

Can you please try adding the same patch as in r117888 to the Geant4 port?

No, I never played with Portfile.. but if you think it is the same issue, you should fix it in the same manner.

Ciao, Angelo.

[hapaguy (Brian Kurt Fujikawa)]

Cc Me!

[mojca (Mojca Miklavec)]

About playing with the Portfile ... just run

cd $(port dir geant4)

and add those two lines to the Portfile and try to rebuild. (The command port selfupdate overwrites that, but you would have a working port by that time.)

I blindly applied the patch in r117906 now. I'm now curious how the commit r117901 interferes with building Geant4 (with the set of allowed compilers).

Also, maybe ​ROOT's commit can give a hint of what is needed to get CLHEP working properly under clang >= 3.4.

[graziosi.angelo@…]

Replying to mojca@…:

About playing with the Portfile ... just run

cd $(port dir geant4)

and add those two lines to the Portfile and try to rebuild. (The command port selfupdate overwrites that, but you would have a working port by that time.)

Thanks for suggestions...

I blindly applied the patch in r117906 now. I'm now curious how the commit r117901 interferes with building Geant4 (with the set of allowed compilers).

Now Geant4 upgrades... and ROOT too,

$ sudo port upgrade outdated
--->  Computing dependencies for root
--->  Fetching archive for root
--->  Attempting to fetch root-5.34.18_0+avahi+cocoa+fftw3+fitsio+gcc48+graphviz+gsl+ldap+minuit2+mysql55+odbc+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+sqlite3+ssl+tmva+xml+xrootd.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/root
--->  Attempting to fetch root-5.34.18_0+avahi+cocoa+fftw3+fitsio+gcc48+graphviz+gsl+ldap+minuit2+mysql55+odbc+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+sqlite3+ssl+tmva+xml+xrootd.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/root
--->  Attempting to fetch root-5.34.18_0+avahi+cocoa+fftw3+fitsio+gcc48+graphviz+gsl+ldap+minuit2+mysql55+odbc+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+sqlite3+ssl+tmva+xml+xrootd.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/root
--->  Fetching distfiles for root
--->  Attempting to fetch root_v5.34.18.source.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/root
--->  Attempting to fetch root_v5.34.18.source.tar.gz from http://root.cern.ch/download/
--->  Verifying checksums for root
--->  Extracting root
--->  Applying patches to root
--->  Configuring root
--->  Building root
--->  Staging root into destroot
--->  Installing root @5.34.18_0+avahi+cocoa+fftw3+fitsio+gcc48+graphviz+gsl+ldap+minuit2+mysql55+odbc+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+sqlite3+ssl+tmva+xml+xrootd
--->  Cleaning root
--->  Computing dependencies for root
--->  Deactivating root @5.34.17_0+avahi+cocoa+fftw3+fitsio+gcc48+graphviz+gsl+ldap+minuit2+mysql55+odbc+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+sqlite3+ssl+tmva+xml+xrootd
--->  Cleaning root
--->  Activating root @5.34.18_0+avahi+cocoa+fftw3+fitsio+gcc48+graphviz+gsl+ldap+minuit2+mysql55+odbc+opengl+postgresql92+pythia+python32+qt_mac+roofit+ruby+soversion+sqlite3+ssl+tmva+xml+xrootd
--->  Cleaning root
Portfile changed since last build; discarding previous state.
--->  Computing dependencies for geant4.9.6
--->  Fetching archive for geant4.9.6
--->  Attempting to fetch geant4.9.6-4.9.6.p02_1+gdml+qt.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/geant4.9.6
--->  Attempting to fetch geant4.9.6-4.9.6.p02_1+gdml+qt.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/geant4.9.6
--->  Attempting to fetch geant4.9.6-4.9.6.p02_1+gdml+qt.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/geant4.9.6
--->  Fetching distfiles for geant4.9.6
--->  Attempting to fetch geant4.9.6.p02.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/geant4
--->  Verifying checksums for geant4.9.6
--->  Extracting geant4.9.6
--->  Applying patches to geant4.9.6
--->  Configuring geant4.9.6
--->  Building geant4.9.6
--->  Staging geant4.9.6 into destroot
--->  Installing geant4.9.6 @4.9.6.p02_1+gdml+qt
--->  Cleaning geant4.9.6
--->  Computing dependencies for geant4.9.6
--->  Deactivating geant4.9.6 @4.9.6.p02_0+gdml+qt
--->  Cleaning geant4.9.6
--->  Activating geant4.9.6 @4.9.6.p02_1+gdml+qt

NOTE: Use 'sudo port select geant4 geant4.9.6'
      if you need geant4-config or geant4.(c)sh in PATH.
      Otherwise source /opt/local/libexec/Geant4/Geant4.9.6/geant4.(c)sh

--->  Cleaning geant4.9.6
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.

Also, maybe ​ROOT's commit can give a hint of what is needed to get CLHEP working properly under clang >= 3.4.

I would suggest to follow FRM...

Ciao (oops... happy sleeping!), Angelo.

[hansbogert@…]

I've added another log, because the build is still failing. Port decides to have llvm-gcc42 as a dependency now for geant in my case.

[mojca (Mojca Miklavec)]

Just to copy the relevant part of the log:

Using compiler 'MacPorts LLVM-GCC 4.2'

...

/opt/local/bin/llvm-g++-4.2  -pipe -Os -I/opt/local/include -arch x86_64 -W -Wall -pedantic -Wno-non-virtual-dtor -Wno-long-long -Wwrite-strings -Wpointer-arith -Woverloaded-virtual -pipe -std=c++98 -DNDEBUG -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o ../../outputs/library/Darwin-g++/libG4graphics_reps.dylib -install_name /opt/local/lib/Geant4/Geant4.9.6/libG4graphics_reps.dylib CMakeFiles/G4graphics_reps.dir/src/G4AttCheck.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttDef.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttDefStore.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttHolder.cc.o CMakeFiles/G4graphics_reps.dir/src/G4AttUtils.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Circle.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Colour.cc.o CMakeFiles/G4graphics_reps.dir/src/G4DimensionedTypeUtils.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBS.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBSbox.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBScylinder.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBShexahedron.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBStube.cc.o CMakeFiles/G4graphics_reps.dir/src/G4NURBStubesector.cc.o CMakeFiles/G4graphics_reps.dir/src/G4PlacedPolyhedron.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Point3DList.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Polyhedron.cc.o CMakeFiles/G4graphics_reps.dir/src/G4PolyhedronArbitrary.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Polyline.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Polymarker.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Scale.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Square.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Text.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VGraphicsScene.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VMarker.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VVisManager.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VisAttributes.cc.o CMakeFiles/G4graphics_reps.dir/src/G4VisExtent.cc.o CMakeFiles/G4graphics_reps.dir/src/G4Visible.cc.o CMakeFiles/G4graphics_reps.dir/src/HepPolyhedron.cc.o ../../outputs/library/Darwin-g++/libG4global.dylib ../../outputs/library/Darwin-g++/libG4intercoms.dylib ../../outputs/library/Darwin-g++/libG4global.dylib /opt/local/lib/libCLHEP.dylib -Wl,-rpath,/opt/local/lib
Undefined symbols for architecture x86_64:
  "HepGeom::operator<<(std::basic_ostream<char, std::char_traits<char> >&, HepGeom::BasicVector3D<double> const&)", referenced from:
      operator<<(std::basic_ostream<char, std::char_traits<char> >&, G4Point3DList const&)in G4Point3DList.cc.o
      operator<<(std::basic_ostream<char, std::char_traits<char> >&, G4VMarker const&)in G4VMarker.cc.o
ld: symbol(s) not found for architecture x86_64

I would be really grateful for some additional help, testing and debugging to figure out why this fails in the first place.

But other than that: which compiler deserves blacklisting now?

I discovered that Geant4 builds just fine with the built-in CLHEP, so now I'm also chasing the reason why it fails when external CLHEP is present even if it's not being used (that might be related to #42872). The reason for using the external CLHEP is at least Gate which isn't happy with the built-in version for some reason (the author is working on fixing that, but it might take some time before it's done; from what I understand he has some come in his local/private branch).

[marcchamberland@…]

Just chiming in that the build also fails for me.

I'd be happy to help in any way I can. I'm resourceful, but my programming knowledge is limited.

[mojca (Mojca Miklavec)]

Out of curiosity: does it help if you blacklist macports-llvm-gcc-4.2?

Does the following work?

sudo port -v install geant4.10.0 configure.compiler=macports-clang-3.3

[hapaguy (Brian Kurt Fujikawa)]

I am working with three OS X 10.9.2 Macs with Xcode 5.1. For some unknown reason that I am still trying to investigate, the default geant4.10.0 build was successful on two and failed on one.

Anyway, the following worked for me on the one Mac where the default geant4.10.0 build failed:

sudo port -sv install geant4.10.0 configure.compiler=macports-clang-3.3

[marcchamberland@…]

Replying to mojca@…:

Out of curiosity: does it help if you blacklist macports-llvm-gcc-4.2?

Does the following work?

sudo port -v install geant4.10.0 configure.compiler=macports-clang-3.3

Blacklisting macports-llvm-gcc-4.2 did not help.

The command for installing Geant4 10.0 worked, though.

[mojca (Mojca Miklavec)]

Which compiler was used then when you blacklisted macports-llvm-gcc-4.2?

[cjones051073 (Chris Jones)]

Hi,

Build géant 4.10.0 on OSX 10.9, with the blacklist as currently in the port

compiler.blacklist  {clang > 503} macports-clang-3.4 macports-clang-3.5

The build ends up resorting to the compiler /opt/local/bin/llvm-g++-4.2, which immediately struck me as probably not a great choice, and ultimately fails with

/opt/local/bin/llvm-g++-4.2  -pipe -Os -I/opt/local/include -arch x86_64 -W -Wall -pedantic -Wno-non-virtual-dtor -Wno-long-long -Wwrite-strings -Wpointer-arith -Woverloaded-virtual -Wno-variadic-macros -Wshadow -pipe -std=c++98 -DNDEBUG -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o ../../outputs/library/Darwin-g++/libG4analysis.dylib -install_name /opt/local/lib/Geant4/Geant4.10.0/libG4analysis.dylib CMakeFiles/G4analysis.dir/csv/src/G4CsvAnalysisManager.cc.o CMakeFiles/G4analysis.dir/csv/src/G4CsvFileManager.cc.o CMakeFiles/G4analysis.dir/csv/src/G4CsvNtupleManager.cc.o CMakeFiles/G4analysis.dir/hntools/src/G4H1DummyManager.cc.o CMakeFiles/G4analysis.dir/hntools/src/G4H1ToolsManager.cc.o CMakeFiles/G4analysis.dir/hntools/src/G4H2DummyManager.cc.o CMakeFiles/G4analysis.dir/hntools/src/G4H2ToolsManager.cc.o CMakeFiles/G4analysis.dir/management/src/G4AnalysisVerbose.cc.o CMakeFiles/G4analysis.dir/management/src/G4AnalysisManagerState.cc.o CMakeFiles/G4analysis.dir/management/src/G4AnalysisMessenger.cc.o CMakeFiles/G4analysis.dir/management/src/G4BaseAnalysisManager.cc.o CMakeFiles/G4analysis.dir/management/src/G4AnalysisUtilities.cc.o CMakeFiles/G4analysis.dir/management/src/G4BinScheme.cc.o CMakeFiles/G4analysis.dir/management/src/G4Fcn.cc.o CMakeFiles/G4analysis.dir/management/src/G4FileMessenger.cc.o CMakeFiles/G4analysis.dir/management/src/G4H1Messenger.cc.o CMakeFiles/G4analysis.dir/management/src/G4H2Messenger.cc.o CMakeFiles/G4analysis.dir/management/src/G4HnManager.cc.o CMakeFiles/G4analysis.dir/management/src/G4HnMessenger.cc.o CMakeFiles/G4analysis.dir/management/src/G4VAnalysisManager.cc.o CMakeFiles/G4analysis.dir/management/src/G4VFileManager.cc.o CMakeFiles/G4analysis.dir/management/src/G4VH1Manager.cc.o CMakeFiles/G4analysis.dir/management/src/G4VH2Manager.cc.o CMakeFiles/G4analysis.dir/management/src/G4VNtupleManager.cc.o CMakeFiles/G4analysis.dir/root/src/G4RootAnalysisManager.cc.o CMakeFiles/G4analysis.dir/root/src/G4RootFileManager.cc.o CMakeFiles/G4analysis.dir/root/src/G4RootNtupleManager.cc.o CMakeFiles/G4analysis.dir/xml/src/G4XmlAnalysisManager.cc.o CMakeFiles/G4analysis.dir/xml/src/G4XmlFileManager.cc.o CMakeFiles/G4analysis.dir/xml/src/G4XmlNtupleManager.cc.o ../../outputs/library/Darwin-g++/libG4global.dylib ../../outputs/library/Darwin-g++/libG4intercoms.dylib ../../outputs/library/Darwin-g++/libG4zlib.dylib ../../outputs/library/Darwin-g++/libG4global.dylib /opt/local/lib/libCLHEP.dylib -Wl,-rpath,/opt/local/lib 
make[2]: Leaving directory `/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_dports_science_geant4/geant4.10.0/work/build'
/opt/local/bin/cmake -E cmake_progress_report /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_dports_science_geant4/geant4.10.0/work/build/CMakeFiles  3
[  6%] Built target G4analysis
make[1]: Leaving directory `/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_dports_science_geant4/geant4.10.0/work/build'
make: *** [all] Error 2

If I simply comment out the blacklist, and try again, the build proceeds and finishes just fine.

So it appears, at least for OSX10.9, and geant4.10.0, the blacklist is too restrictive, and is preventing use of the default clang compiler (which is always the best one to use, if it works, I think), which works fine. I haven't tested any other geant4 versions though, so perhaps others have problems. If they do, then that shouldn't prevent the use of the system clang with 10.0, and the blacklist should then be version specific...

Chris

[cjones051073 (Chris Jones)]

If I blacklist macports-llvm-gcc-4.2, then it attempts to use apple-gcc42, which I think is even less likely to be the right compiler, at least on OSX10.9. Given the default clang compiler seems to work fine, that should be allowed by the blacklist.

Chris

[cjones051073 (Chris Jones)]

Hi,

I have tested both geant4 versions 4.9.6 and 4.9.5, and both build fine on OSX 10.9 with the default system compiler (clang) if I comment out the current compiler blacklist.

So I can confirm the current blacklist is too restrictive, at least as far as OSX10.9 is concerned, and the default system compiler on this system should be allowed. the compiler is

macmini ~ > clang -v
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

So I simply propose removing the {clang > 503} from the backlist.

cheers Chris

[cjones051073 (Chris Jones)]

Cc Me!

[mojca (Mojca Miklavec)]

See #42999.

[mojca (Mojca Miklavec)]

I would be grateful if someone could confirm that compiling geant4.10.0 +clhep works on 10.9 with default compiler now (the patch was added to CLHEP on 5th May). Not that it matters any longer because we now switched to the built-in CLHEP anyway, but still ...

[mojca (Mojca Miklavec)]

Most likely fixed in the latest CLHEP version (r120006).