[OSX] Multiply defined symbols between Function and Signals libs ?
Hi I'v been compiling boost libraries objects straight into my application binaries on linux and OSX platforms (e.g. not using bjam/stat/dynlibs), and thus far it has worked. However, recently I started getting multiply defined symbols on OSX, namely _1, _2, _3 etc. Most likely they come between Boost.Function and Boost.Signals libraries (latter of which I started using recently). My question is is it inherently bad idea to compile boost objects like this straight into application binary (e.g. should I always use bjam?), or there any other workarounds to avoid those multiple symbols on OSX ? Alo Sarv.
Alo Sarv wrote:
I'v been compiling boost libraries objects straight into my application binaries on linux and OSX platforms (e.g. not using bjam/stat/dynlibs), and thus far it has worked. However, recently I started getting multiply defined symbols on OSX, namely _1, _2, _3 etc. Most likely they come between Boost.Function and Boost.Signals libraries (latter of which I started using recently).
_1, _2 and so on can come from either Boost.Bind or Boost.Lambda. If you are
using Boost.Bind, these are defined in
Peter Dimov wrote:
Alo Sarv wrote:
I'v been compiling boost libraries objects straight into my application binaries on linux and OSX platforms (e.g. not using bjam/stat/dynlibs), and thus far it has worked. However, recently I started getting multiply defined symbols on OSX, namely _1, _2, _3 etc. Most likely they come between Boost.Function and Boost.Signals libraries (latter of which I started using recently).
_1, _2 and so on can come from either Boost.Bind or Boost.Lambda. If you are using Boost.Bind, these are defined in
. Take a look at this file, and you'll see three different compiler-specific paths, of which you are probably using the last (g++ on OSX, right?) Since the placeholders are defined in an unnamed namespace, there shouldn't be any multiple definition errors, so it's probably a compiler bug. Check whether you have two source files with the same name, as this may be the cause. Otherwise, as a last resort, you may try editing placeholders.hpp so that one of the other #ifdef sections is selected.
Well, I currently resolved the problem by rearranging some #includes in my headers. However, the real fix is described here: http://developer.apple.com/technotes/tn2002/tn2071.html#Section7 So the real fix would be to use -multiply-defined supress compiler flag. So, not a compiler bug, a compiler feature :) Alo Sarv.
participants (2)
-
Alo Sarv -
Peter Dimov