Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-61433

Boost thread compilation warning with new glibc

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • ALL
    • Dev Platform 2021-12-27

      Building with the latest pthread headers produces a warning in Boost::Thread

      In file included from src/third_party/boost/boost/thread/thread_only.hpp:17,
                       from src/third_party/boost/boost/thread/thread.hpp:12,
                       from src/third_party/boost/boost/log/sinks/async_frontend.hpp:38,
                       from src/third_party/boost/boost/log/sinks.hpp:25,
                       from src/mongo/shell/mongo_main.cpp:40:
      src/third_party/boost/boost/thread/pthread/thread_data.hpp: In member function ‘void boost::thread_attributes::set_stack_size(std::size_t)’:
      src/third_party/boost/boost/thread/pthread/thread_data.hpp:61:19: error: comparison of integer expressions of different signedness: ‘std::size_t’ {aka ‘long unsigned int’} and ‘long int’ [-Werror=sign-compare]
                 if (size<PTHREAD_STACK_MIN) size=PTHREAD_STACK_MIN;
      

      This is due to the macro definition for PTHREAD_STACK_MIN changing from a numeric literal to a function call that returns a long int. This started failing for me when I upgraded to Fedora 35.

      Workaround is to build with --disable-warnings-as-errors
      Potential fixes include upgrading to a version of Boost::Thread with the fix; hacking our vendored Boost to avoid the warning; playing with macros like __USE_DYNAMIC_STACK_SIZE to avoid the problematic definition.

            Assignee:
            andrew.morrow@mongodb.com Andrew Morrow (Inactive)
            Reporter:
            milkie@mongodb.com Eric Milkie
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: