Hi all, I'm using header-only boost libs in two static libraries that will be linked into an executable. No boost components are used in the interfaces of those libs, boost is only used in the implementation inside the libraries. Is it possible to mix versions of boost in those two static libraries? Will the linker complain, or will it just get confused and mess up the executable? The problem here is that one of those libraries is 'external', that is, I'm getting it compiled and with no source code (only .h for interface) TIA PS: I admit this is more a C++ linker question, but maybe someone out there has had to coexist with different versions of boost
dariomt@gmail.com wrote:
Hi all,
I'm using header-only boost libs in two static libraries that will be linked into an executable.
No boost components are used in the interfaces of those libs, boost is only used in the implementation inside the libraries.
Is it possible to mix versions of boost in those two static libraries? Will the linker complain, or will it just get confused and mess up the executable?
In general, this is highly risky business. On GCC, each static library will contain a copy of every template function used by a static library. If the linker finds that the same function is used in both static libraries, it will put only one copy in the output executable, and if the definitions of those functions differ, you're in trouble. See the attached example, which, then run, produces: a.cpp:say a.cpp:say Which is clearly wrong. This *might* work with shared libraries, but you need to consult your toolchain documentation. There's nothing Boost can do to help here, except maybe changing namespace name with each version. - Volodya
Vladimir Prus wrote:
dariomt@gmail.com wrote:
Hi all,
I'm using header-only boost libs in two static libraries that will be linked into an executable.
No boost components are used in the interfaces of those libs, boost is only used in the implementation inside the libraries.
Is it possible to mix versions of boost in those two static libraries? Will the linker complain, or will it just get confused and mess up the executable?
In general, this is highly risky business. On GCC, each static library will contain a copy of every template function used by a static library. If the linker finds that the same function is used in both static libraries, it will put only one copy in the output executable, and if the definitions of those functions differ, you're in trouble. See the attached example, which, then run, produces:
a.cpp:say a.cpp:say
Which is clearly wrong. This *might* work with shared libraries, but you need to consult your toolchain documentation.
For the past few years we've had a GCC option that allows you to expose from dynamic libs only those names you specify, sort of like declspec on Windows. I don't remember the name of the flag, though. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Why not to introduce an additional level of indirection ;) Just wrap the 3d-Party lib in a DLL (or Shared Object under Linux), than you should be find to use 2 libs with each other... The only point to be careful about if 3d-party lib returns boost class instances. These might be different in a newer version of the lib. With Kind Regards, Ovanes On Wed, Jun 25, 2008 at 6:41 PM, David Abrahams <dave@boostpro.com> wrote:
Vladimir Prus wrote:
dariomt@gmail.com wrote:
Hi all,
I'm using header-only boost libs in two static libraries that will be linked into an executable.
No boost components are used in the interfaces of those libs, boost is only used in the implementation inside the libraries.
Is it possible to mix versions of boost in those two static libraries? Will the linker complain, or will it just get confused and mess up the executable?
In general, this is highly risky business. On GCC, each static library will contain a copy of every template function used by a static library. If the linker finds that the same function is used in both static libraries, it will put only one copy in the output executable, and if the definitions of those functions differ, you're in trouble. See the attached example, which, then run, produces:
a.cpp:say a.cpp:say
Which is clearly wrong. This *might* work with shared libraries, but you need to consult your toolchain documentation.
For the past few years we've had a GCC option that allows you to expose from dynamic libs only those names you specify, sort of like declspec on Windows. I don't remember the name of the flag, though.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
David Abrahams wrote:
Vladimir Prus wrote:
dariomt@gmail.com wrote:
Hi all,
I'm using header-only boost libs in two static libraries that will be linked into an executable.
No boost components are used in the interfaces of those libs, boost is only used in the implementation inside the libraries.
Is it possible to mix versions of boost in those two static libraries? Will the linker complain, or will it just get confused and mess up the executable?
In general, this is highly risky business. On GCC, each static library will contain a copy of every template function used by a static library. If the linker finds that the same function is used in both static libraries, it will put only one copy in the output executable, and if the definitions of those functions differ, you're in trouble. See the attached example, which, then run, produces:
a.cpp:say a.cpp:say
Which is clearly wrong. This *might* work with shared libraries, but you need to consult your toolchain documentation.
For the past few years we've had a GCC option that allows you to expose from dynamic libs only those names you specify, sort of like declspec on Windows. I don't remember the name of the flag, though.
-fvisibility, I believe. I actually though there's a way to cause a shared library to prefer its own symbols -- but apparently it's not possible, at least with gcc, in any easy way. - Volodya
participants (4)
-
dariomt＠gmail.com -
David Abrahams -
Ovanes Markarian -
Vladimir Prus