1

I have been using the boost iostream library (version 1.65) mostly using following header: <boost/iostreams/filtering_streambuf.hpp> , with no problems.

After I added another library called cpprest to my project(https://github.com/Microsoft/cpprestsdk). I get this warning in my cmake: 

usr/bin/ld: warning: libboost_system.so.1.58.0, needed by /usr/lib/libcpprest.so, may conflict with libboost_system.so.1.65.0

Also after including the boost headers, I get this mysterious compile error:

/usr/local/include/boost/iostreams/detail/access_control.hpp: In constructor ‘boost::iostreams::detail::prot_<U>::prot_(V)’:
/usr/local/include/boost/iostreams/detail/access_control.hpp:37:43: error: class ‘boost::iostreams::detail::prot_<U>’ does not have any field named ‘v’
         template<typename V> prot_(V v) : U(v) { }

Is this caused by the incompatibility of Boost 1.58 (which is used by cpprest) and 1.65? Or is it a bug in Boost iostream?

I actually down-graded my boost to 1.58 but I still see the same error.

motam79
  • 3,542
  • 5
  • 34
  • 60

2 Answers2

2

Yes this looks like a version conflict.

Note that since it is a compile error on the implementation details of access_control, it could very well be due to different compiler flags/config resulting in different code being compiled in. This would be a problem even if all includes are from the same Boost release.

In particular, some part of the code may be making (different) assumptions about the target platform.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • 1
    After a long search I figured out it was a problem with the definitions. Microsoft code defines a macro call U(x) and the Boost code uses U as template variable. :) After adding #define _TURN_OFF_PLATFORM_STRING the problem was resolved. Is there a way to detect these collision in other ways? Because the compiler message was not very helpful. – motam79 Jul 01 '18 at 12:46
  • 1
    The compiler message would have made perfect sense if you just looked at the same code as the compiler did. I.e. you should try looking at the preprocessed source next time (and avoid mixing headers of different libraries, when they are not header-clean. Sadly that's a painful tradition with Microsoft libraries (windows.h is a pretty big offender e.g.)) – sehe Jul 01 '18 at 12:49
  • PS. You might add an answer of your own and accept that instead. I'm glad you found my answer helpful, but you found the culprit yourself – sehe Jul 01 '18 at 12:49
2

I figured out it was a problem with the definitions. The Microsoft code defines a macro call U(x) and the Boost code uses U as template variable. After adding #define _TURN_OFF_PLATFORM_STRING before importing the Microsoft code header, the problem was resolved.

motam79
  • 3,542
  • 5
  • 34
  • 60