Hundred of C++ linker warnings in Xcode 3: odd but not fatal
Hundred of C++ linker warnings in Xcode 3: odd but not fatal
- Subject: Hundred of C++ linker warnings in Xcode 3: odd but not fatal
- From: Shamyl Zakariya <email@hidden>
- Date: Sun, 2 Dec 2007 11:02:29 -0500
I have a fairly large C++ project which uses boost pretty extensively.
It's a physics simulation and visualization framework, which gets
bundled into C++ apps.
Now, most of the boost stuff I use is header based, such as
Boost.Bind, and shared_ptr<> and the like. But, I also use
Boost.Python, which doesn't compile out of the box into a library in /
usr/local/lib. So, to use Boost.Python, I have a sub-target in my
framework's build which builds a local static lib libboostpython.a,
which is linked against when the final framework is linked.
Under Xcode 2.4, this worked fine. In fact, it still works fine with
Xcode 3 -- e.g., it produces a working executable -- but I get
*hundreds* of linker warnings about differing visibility:
Here's one example ( I get this warning for every class using
boost.python ):
ld: warning
boost::python::type_info::operator==(boost::python::type_info const&)
consthas different visibility (2) in /Users/zakariya/Code/Projects/
SimRenderingEngine/trunk/build/Debug/libboostpython.a(registry.o) and
(1) in /Users/zakariya/Code/Projects/SimRenderingEngine/trunk/build/
SimRenderingEngine.build/Debug/SimRenderingEngine.build/Objects-normal/
i386/BallJoint.o
I suspect the problem lies in the class BallJoint calling boost.python
methods for exposing its interface to python. BallJoint is calling
boost.python's binding methods:
BOOST_PYTHON_MODULE(BallJointProxy)
{
using namespace boost::python;
class_<BallJointProxy, shared_ptr< BallJointProxy >, bases<
ConstructProxy > >("BallJointProxy", no_init )
.def( "error", &BallJoint::error );
}
Presumably these macros and methods are being extracted from /usr/
local/include/boost/python/ and being expanded in my framework. But I
suppose these are also being expanded in the static library
libboostpython.a which my framework is linking against.
ld is doing the right thing, ultimately and giving me a functional
executable. But I'm curious if there's anything I can do to quiet
these warnings. I'm one of those "it's not compiling correctly until
there are no warnings" type of programmers, so seeing 851 linker
warnings in my build process is unsettling.
The obvious solution is to make my build of boost.python not a
separate static lib but rather build it directly into my framework.
But keeping it separate seems clean to me.
Does anybody have any suggestions? Are there some magic build flags
which will quiet this? Or is this indicating a bigger fundamental
problem which I should be aware of?
Shamyl Zakariya
"Simplicate, then add lightness"
- Colin Chapman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden