[CLHEP-103] Build/linking failure with clang 3.4: Undefined symbols Created:
16/Mar/14 Updated: 13/May/14 Resolved: 13/May/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
CLHEP
None
2.1.4.x
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Mojca Miklavec
Fixed
None
Not Specified
External issue
ID:
External issue
URL:
Savannah Fields
Container:
bugs104110
None
Priority:
Assignee:
Votes:
Major
Lynn Garren
0
Not Specified
Not Specified
http://savannah.cern.ch/bugs/?104110
Item Group: None
Operating System: other (please specify compiler version as well)
Description
Building CLHEP fails when using clang version 3.4:
Linking CXX shared library ../../lib/libCLHEP-RandomObjects2.1.4.1.dylib
/opt/local/bin/clang++-mp-3.4 -O2 -g -DNDEBUG -dynamiclib Wl,-headerpad_max_install_names
-o ../../lib/libCLHEPRandomObjects-2.1.4.1.dylib -install_name /path/to/clhepbuild/lib/libCLHEP-RandomObjects-2.1.4.1.dylib
CMakeFiles/RandomObjects.dir/RandMultiGauss.cc.o
CMakeFiles/RandomObjects.dir/RandomVector.cc.o
../../lib/libCLHEP-Random-2.1.4.1.dylib ../../lib/libCLHEPMatrix-2.1.4.1.dylib ../../lib/libCLHEP-Vector-2.1.4.1.dylib
../../lib/libCLHEP-Random-2.1.4.1.dylib
Undefined symbols for architecture x86_64:
"CLHEP::HepVector::num_row() const", referenced from:
CLHEP::HepRandomVector::operator()() in
RandomVector.cc.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v
to see invocation)
make[2]: *** [lib/libCLHEP-RandomObjects-2.1.4.1.dylib] Error
1
make[1]: ***
[RandomObjects/src/CMakeFiles/RandomObjects.dir/all] Error 2
make: *** [all] Error 2
This has been tested and confirmed on Mac OS X 10.9 with Xcode 5.1 (Apple just switched to
clang 3.4 as the default compiler) as well as on Mac OS X 10.7 where CC/CXX has explicitly
been set to clang version 3.4. Compiling with clang version 3.3 works ok. There is a fair chance
that the same problem can be reproduced on linux, but I didn't try it.
I'm unable to figure out if this is an actual compiler bug or if the compiler just became more
"picky" about the code. In case it's a compiler bug, it would be very desirable to find a
minimum example reproducing the problem and submitting an upstream bug report. In case the
compiler is being "picky", it would be great to fix this.
Comments
Comment by Mojca Miklavec [ 17/Mar/14 ]
A related problem is also present when building Geant4:
Undefined symbols for architecture x86_64:
"HepGeom::operator<<(std::__1::basic_ostream<char,
std::__1::char_traits<char> >&, HepGeom::BasicVector3D<double>
const&amp\;)", referenced from:
operator<<(std::__1::basic_ostream<char,
std::__1::char_traits<char> >&, G4Point3DList const&amp\;) in
G4Point3DList.cc.o
operator<<(std::__1::basic_ostream<char,
std::__1::char_traits<char> >&, G4VMarker const&amp\;) in
G4VMarker.cc.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v
to see invocation)
It looks like ROOT had similar issues based on commit message (and requests for a quick
update due to build failures with latest Xcode):
https://github.com/root-mirror/root/commit/4da8475ff345d6c34c6537f2bcaf8cd56741199e
Comment by Benedikt Hegner [ 01/Apr/14 ]
Faced the same problem and the problem can be traced down to having inline definitions in the
.cc file. This fixes it:
--- CLHEP/Matrix/src/Vector.cc.orig
09:21:25.000000000 +0200
+++ CLHEP/Matrix/src/Vector.cc
09:22:17.000000000 +0200
@@ -114,9 +114,9 @@
2014-04-01
2014-04-01
// trivial methods
-inline int HepVector::num_row() const {return nrow;}
-inline int HepVector::num_size() const {return nrow;}
-inline int HepVector::num_col() const { return 1; }
+int HepVector::num_row() const {return nrow;}
+int HepVector::num_size() const {return nrow;}
+int HepVector::num_col() const { return 1; }
// operator()
Comment by Mojca Miklavec [ 01/Apr/14 ]
Thank you. This solved the problem for me as well.
(The problem with Geant4 might need a patch as well, but I didn't try it yet.)
Comment by Derrick Mancini [ 09/Apr/14 ]
This worked for us too, OSX 10.9.2, Xcode 5.1
Comment by Tom Roberts [ 29/Apr/14 ]
This patch also worked for me, OSX 10.9.2 (Mavericks), Xcode 5.1.1.
NOTE: there are other inline functions in Vector.cc. While they did not fail the build, they
should be investigated. Perhaps they are not used in any other .cc file.
When I build geant4, I use its internal version of CLHEP, which avoids this.
Comment by Lynn Garren [ 05/May/14 ]
Thanks Benedikt. There is no reason for any CLHEP .cc file to contain inline methods. I have
removed the inlines from Vector.cc in preparation for the next release.
Comment by Mojca Miklavec [ 05/May/14 ]
Thank you for looking into this. What about the errors when compiling Geant4 against CLHEP?
Comment by Lynn Garren [ 13/May/14 ]
Now available in CLHEP 2.1.4.2:
http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/
Comment by Mojca Miklavec [ 13/May/14 ]
Thank you. It looks like Geant4 now compiles properly as well.
Generated at Wed Feb 10 02:23:31 CET 2016 using JIRA 6.4.9#64024sha1:1f1084e06c9893c77549621edbccfecfaa68be5d.