0

I used boost log in multiple project and just discovered a limitation in the way I should use/build the lib depending of the software component type static or shared I develop ode see here

The library has a separately compiled part which should be built as described in the Getting Started guide. One thing should be noted, though. If your application consists of more than one module (e.g. an exe and one or several dll's) that use Boost.Log, the library must be built as a shared object. If you have a single executable or a single module that works with Boost.Log, you may build the library as a static library.

Have an explanation/reason for that limitation ?

Praetorian
  • 106,671
  • 19
  • 240
  • 328
alexbuisson
  • 7,699
  • 3
  • 31
  • 44
  • 1
    Because you want your entire application to use a single Boost.Log instance, instead of having each module that links to it having a separate instance. – Praetorian Feb 05 '14 at 17:19
  • so it means that if you plan to deliver a DLL for integration in a system you don"t know your only way is to build / link everything as shared (DLL or SO) ? is it because there is a static singleton define somewhere in the boost log implemtatoon ? – alexbuisson Feb 05 '14 at 17:27
  • Answer to first question is yes. Second one - I have no idea what causes that limitation. Your best bet probably is asking on the Boost mailing list if you really want to know the answer to that question. – Praetorian Feb 05 '14 at 18:19

1 Answers1

1

This is because this library contains objects with internal linkage and static storage duration. Putting such objects into a shared library helps to make sure that there are no duplicates of such objects at run-time.

Note that static storage duration objects with external linkage do not suffer from this: if there is a duplicate definition at link time - the linker complains, at run-time - only the first available definition is used.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271