Building log for dynamic linking by default

Help
2013-01-14
2014-03-25
  • Chris Stylianou

    Chris Stylianou - 2013-01-14

    Hi, I was wondering if anyone could help.

    I'm trying to build and use the newer Boost.Log v2 for my projects and have noticed the default behaviour of library linking has changed from dynamic to static. I know this can be changed by defining BOOST_LOG_DYN_LINK in each project file, to enforce dynamic linking. However, we always use the shared library as I use Boost.Log throughout our libraries and applicaitons.

    Is there a method of build Boost.Log so that it defualts to using the shared library? It seems a bit silly that I have to define  BOOST_LOG_DYN_LINK everywhere.

    I follow the normal build process as set out in the Getting Started Guide (Download boost and boost-log v2, copy boost-log v2 into boost, then run '.\bootstrap.sh' and 'sudo .\b2 install')

    Thanks
    Chris

     
  • Andrey Semashev

    Andrey Semashev - 2013-01-14

    The library follows the default build options set by Boost.Build for the target platform, which is probably "build static libs" in your case. Are other Boost libraries built statically as well?

    To define configuration macros globally you can use the boost/config/user.hpp file. The header is included automatically by all libraries.

     
  • Chris Stylianou

    Chris Stylianou - 2013-01-19

    Thanks for the advise, it appears my project was using static boost by default, I've changed it to use BOOST_ALL_DYN_LINK :)

     
  • jmo

    jmo - 2014-03-06

    I'm having a similar issue. We build a bunch of modules, which in turn we link into a bunch of applications. Usually we link the application and modules to dynamic boost libraries, however in one application's case we need to link to boost statically. This is because this particular application uses a third party library that itself links to a bunch of old boost libraries that it ships with. If we don't link statically to the new version of boost, the runtime linker ends up linking the third party library to the wrong version of boost (the new one we're using instead of the old) and KAPOW! app pretty quickly crashes... but I digress. Boost log as of 1.55 requires us to compile user code with the BOOST_LOG_DYN_LINK macro enabled if we're linking to DLLs, but in our case when building our modules (actually just static libraries) it's unknown whether the objects will be eventually linked to dynamic or static boost - that depends on the target application.

    So our builds are now failing at the link stage either on the statically linked app or all the dynamically linked ones depending on whether we set the BOOST_LOG_DYN_LINK macro or not respectively. The old boost log didn't seem to have this requirement imposed on the compilation of user code ... do we really need to compile two versions of our own module code and link appropriately .. is there perhaps some other solution?

     
  • Andrey Semashev

    Andrey Semashev - 2014-03-06

    The linking requirements of Boost.Log hasn't changed since the very start, so if it worked before 1.55 then either you were lucky or there was some other factor to it.

    If rebuilding the third party library with your new Boost is not an option then you have to separate it from Boost.Log so that they are used by different modules. Depending on the application design, there are two choices. You could create a dll that uses the third party library and links with it and the old Boost statically. No other part of the application uses the third party library directly, all interaction with it is done through your dll API. The rest of the application and other modules can use the new Boost as usual. Another way is to do the same with Boost.Log. In this case you link Boost.Log statically into your dll and use it only through the dll API. The rest of the application can link with the third party library and the old Boost statically. Note that in both cases the dll API must not use any Boost in its interface.

    From the point of ability to upgrade Boost I'd prefer the first approach, but your mileage may vary, of course.

     
  • jmo

    jmo - 2014-03-06

    Hi Andrey,

    Thanks for the advice ... not sure which way I'll go but I'll post back once this is resolved.

    FYI I worked out why it used to work - looks like boost log now compiles under a different namespace based on the DYN macro, whereas my old version did not. So my modules would link with whatever provided, static or dynamic lib.

    Is there any reason why you changed it to be this way?

    Here's the old namespace code in detail/prologue.hpp that shows what I mean (whereas now we get different namespaces based on the BOOST_LOG_DLL macro, set from the DYN macro):

    namespace boost {
    
    // Setup namespace name
    #if !defined(BOOST_LOG_DOXYGEN_PASS)
    #   if defined(BOOST_LOG_NO_THREADS)
    #       define BOOST_LOG_NAMESPACE log2_st
    #   else
    #       if defined(BOOST_THREAD_PLATFORM_PTHREAD)
    #           define BOOST_LOG_NAMESPACE log2_mt_posix
    #       elif defined(BOOST_THREAD_PLATFORM_WIN32)
    #           if defined(BOOST_LOG_USE_WINNT6_API)
    #               define BOOST_LOG_NAMESPACE log2_mt_nt6
    #           else
    #               define BOOST_LOG_NAMESPACE log2_mt_nt5
    #           endif // defined(BOOST_LOG_USE_WINNT6_API)
    #       else
    #           define BOOST_LOG_NAMESPACE log2_mt
    #       endif
    #   endif // defined(BOOST_LOG_NO_THREADS)
    namespace BOOST_LOG_NAMESPACE {}
    namespace log = BOOST_LOG_NAMESPACE;
    

    Thanks

     
  • Andrey Semashev

    Andrey Semashev - 2014-03-06

    That code was used before v2 was released. The new naming scheme is cleaner and adds the potential for extension by specializing templates.

     
  • jmo

    jmo - 2014-03-07

    FYI Andrey I decided the simplest way forward was to compile/link all modules against static boost libraries.

    Thanks for your help.

     
  • Daniel

    Daniel - 2014-03-25

    Hi Andrey,

    I'm also trying to build and use the newer Boost.Log v2 for my project that it's just a single module.
    But it failed to build as error information was occurred.

    Please look at the attachment.

    I have tried to get other way to resolve those errors, but it is not work for me.

    I have also defined below in my project.

    BOOST_ALL_STATIC_LINK \ BOOST_LOG_WITHOUT_EVENT_LOG \ BOOST_LIB_DIAGNOSTIC

    And added all of the static libraries like this.

          -lboost_iostreams-mgw48-mt-s-1_55 \
          -lboost_date_time-mgw48-mt-s-1_55 \
          -lboost_exception-mgw48-mt-s-1_55 \
          -lboost_regex-mgw48-mt-s-1_55 \
          -lboost_serialization-mgw48-mt-s-1_55 \
          -lboost_wserialization-mgw48-mt-s-1_55 \
          -lboost_signals-mgw48-mt-s-1_55 \
          -lboost_random-mgw48-mt-s-1_55 \
          -lboost_locale-mgw48-mt-s-1_55 \
          -lboost_exception-mgw48-mt-s-1_55 \
          -lboost_timer-mgw48-mt-s-1_55 \
          -lboost_filesystem-mgw48-mt-s-1_55 \
          -lboost_system-mgw48-mt-s-1_55 \
          -lboost_thread-mgw48-mt-s-1_55 \
          -lboost_log_setup-mgw48-mt-s-1_55 \
          -lboost_log-mgw48-mt-s-1_55 \
          -lboost_program_options-mgw48-mt-s-1_55
    

    Unfortunately, it seems not to work yet.

    So, is there any other ideas for using the Boost.Log?

    Thanks,

    Daniel.Li

     
    Last edit: Daniel 2014-03-25
    Attachments
  • Andrey Semashev

    Andrey Semashev - 2014-03-25

    With GNU linker, the order of libraries in the linker command line matters. Boost.Log uses Boost.Filesystem, so the -lboost_filesystem switch must be specified after -lboost_log and -lboost_log_setup. This also concerns other dependencies.

     
  • Daniel

    Daniel - 2014-03-25

    This afternoon, I were always try to avoid those errors.
    But I have no idea for that totally.
    Now, it works!!
    Cool~

    Really, thank you very much for your advise!!

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks