Re: Hundred of C++ linker warnings in Xcode 3: odd but not fatal
Re: Hundred of C++ linker warnings in Xcode 3: odd but not fatal
- Subject: Re: Hundred of C++ linker warnings in Xcode 3: odd but not fatal
- From: Jerry <email@hidden>
- Date: Sun, 2 Dec 2007 18:01:32 +0000
On 2 Dec 2007, at 16:02, Shamyl Zakariya wrote:
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?
Only 851? I get 4000 warnings every time I build (luckily, the
warnings Xcode shows per architecture seems to be limited to 2000).
I've managed to reduce this (to 4000) by building my own static
libraries with -fvisibility=default, but I've no idea what to do about
third-party static libraries which I don;t have control over. The
warnings are really annoying, increase the build time substantially
and hide any "real" warnings or errors you get.
Jerry
_______________________________________________
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