1

First off I know there are several posts similar to this,but I am going to ask anyway. Is there a known problem with boost program_options::options_description in Debian "Buster" and Boost 1.67 packages?

I have code that was developed back in Debian 7, system upgraded to 8.3 then 8.11 now using Boost 1.55.

Code builds and runs. Now upgrade system to Debian Buster with Boost 1.67 and get the link errors for unresolved reference to options_description(const std::string& , unsigned int, unsigned int) along with several other program_options functions. All unresolved, expect the options_description, are from boost calling another boost function, so not even directly called from within my code. boost_program_options IS in the link line. I AM not a novice and understand link order and this has nothing to do with link order. I am going to try getting the source code for boost and building to see if that works, if not I will be building a system from scratch and testing against that. Since this is all on a closed network simply saying try a newer version of boost or Debian is not an option because I am contractually obligated to only use Debian "Buster" and Boost 1.67 as the newest revisions, so if the package is unavailable (newer) in Buster it is out of the question, without having a new contract be drafted and go through approvals which could take months.

So to the point of this question, is there an issue with the out of the box version of Boost in Buster?

Gary Barnes
  • 73
  • 8
  • tried adding a code example but kept getting an error in the insertion. – Gary Barnes May 21 '20 at 17:26
  • 1
    Check your link error carefully. I think, there should be some references to the old version of the boost, somewhere in the code. In other words, you use the new headers of boost 1.67, but old libs of 1.55. – TonySalimi May 21 '20 at 17:31
  • Old libs appear to have been removed via apt-get purge libboost* – Gary Barnes May 21 '20 at 17:54
  • Check your link errors. Make sure that you have the right references to boost libs. – TonySalimi May 21 '20 at 17:55
  • exact error is "unresolved reference to boost::program_options::options_description::options_description(const std::string& , unsigned int, unsigned int)" All libraries are 1.67.0 – Gary Barnes May 21 '20 at 17:57

1 Answers1

0

I don't think there's gonna be an issue with the package in Buster.

My best bet is that either

  1. you're relinking old objects with the new libraries - and they don't match (did you do a full make clean e.g. to eliminate this possibility?).

    Often build systems do not do complete header dependencies, so the build system might not notice that the boost headers changed, requiring the objects to be be rebuilt.

  2. if that doesn't explain it, there could be another version of boost on the include path, leading to the same problem as under #1 even when rebuilding.

    You could establish this by inspecting the command lines (make -Bsn or compile_commands.json e.g. depending on your tools). Another trick is to include boost/version.hpp and see what BOOST_VERSION evaluates to

  3. Lastly, there could be a problem where the library was built with different compiler version or compiler flags, leading to incompatible synbols (this is a QoI issue that you might want to report with the Boost Developers).

    This is assuming ABI/ODR issues, in case you want to validate this possibility.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Code is being built from scratch, make clean, even from a clean git clone. Even wrote a clean stub .cpp with only line that being 'options_description desc("foo"); still get the error. Rebuilt the boost library and all is good. Found further issues with libraries too being a mismatch. Since the system is on a closed network I still need to determine is debian mirror is out of date. – Gary Barnes Jun 02 '20 at 15:27
  • No other library versions are on the system, so not relinking with old objects either. Therefore #3 above is the only option left that the packages were built with different flags and therefore not compatible with my build. How does one know what the compiler flags were that were used to built the libraries? – Gary Barnes Jun 02 '20 at 15:30
  • You would know from documentation. In the case of deb repos the "documentation" is in deb-src packages which you can inspect/execute locally (debuilder, dpkg-build and friends). – sehe Jun 02 '20 at 17:42
  • But usually you can expect distro packages to stick with distro defaults. So, the distro-default gcc, -O2, -std=c++03 would be typical. Threading would be enabled, but not necessarily ICU, MPI, python (?). – sehe Jun 02 '20 at 17:42
  • One thing I remember being a recurring on some platforms was when the platform GCC was built with ABI compatibility for std::string ([_GLIBCXX_USE_CXX11_ABI](https://stackoverflow.com/questions/34571583/understanding-gcc-5s-glibcxx-use-cxx11-abi-or-the-new-abi)) which was a frequent linkage trap for a while. This is not suggesting this is your issue (too old?) but to give you inspiration for the kind of env dependencies to pay attention to. – sehe Jun 02 '20 at 17:45