More then that, under ELF platforms (Linux, Solaris, BSD) there is even bigger issue because this may happen even if you do not share classes explicitly between libfoo and your app. Because all symbols are uniquely mapped so user of libfoo may get boost-1.35 symbols even if they are used internally.
Now this is an interesting issue. We stumbled over the same issue when discussing how to best integrate boost in CLucene ([1]). I think boost could use a user-controlled name mangling facility so a binary library distributor could make sure the symbols from the boost he ships do not collide with boost symbols in other code. I haven't tried if a -Dboost=boost_1_43 preprocessor flag (applied to both the boost build and the application build) is sufficient, though. Best regards, Isidor [1] http://clucene.sourceforge.net/