-1

I am recompiling some C++ code on Linux Mint which makes use of libboost. The code worked fine before an upgrade from Mint 18 to Mint 19.3. Since then, I can get the code to compile, but during execution it fails with an error generated by one or more calls to boost::filesytem::create_directories

Searching the 'net, it seemed that the problem could be due to library version incompatibilities and sure enough while 1.65 is installed, there appear to be libraries from 1.58 running around, in this folder for example /usr/lib/x86_64-linux-gnu (or something like that).

When I try a 'net solution like sudo rm -f /usr/lib/x86_64-linux-gnu/libboost_* (and then a reinstall) or sudo rm -f /usr/lib/x86_64-linux-gnu/libboost_*.so.1.5.8.0

nothing changes (ie the files seem to remain as do the execution errors).

When I rerun a copy of the compiled code from before, the code doesn't fail.

Can anyone suggest how I can fix this problem? The code I am compiling is massive and not my own, so I don't know where to start in changing the function call. In fact, I don't think that is the problem. What I think I need to know is how to wipe out the remnants of the older install and/or repoint everything to the latest install.

FWIW, I've tried the advice here Uninstall boost and install another version and it doesn't seem to move me along.

halfer
  • 19,824
  • 17
  • 99
  • 186
mconsidine
  • 53
  • 3
  • 1
    Why do you think it's a problem with the boost version and not with a different library? Is the code statically or dynamically linked? You can check which dynamic libraries are used with `ldd` – Thomas Sablik Jan 23 '20 at 19:14
  • I had come across a comment by someone (reference now lost) that seemed to have the same problem. When I use your suggestion, I only see references to the most recent version installed (1.65). The prior-compiled version of the code linked to version 1.58. Nothing changed with respect to the source code - I'm just running the exact same compile commands. And since I had not found any reference to the calls to create_directories changing, I figured the only left was a problem with which versions of the libraries it was linking to. – mconsidine Jan 24 '20 at 18:41
  • It turns out from reviewing release notes on the boost site that there was a fix related to create_directories which was applied in version 1.60. What I did was download versions 1.58, 1.60, and 1.72, installing each of them in their own locations so that I didn't stomp on the system default (1.65). Then I used EXT_HINT to preferentially select and verify the version used when cmake was run. The only resulting binary that worked with the existing code was the one with version 1.58. So I'm going to leave it at that (ie compiling against 1.58) and consider this solved for my purposes. – mconsidine Jan 25 '20 at 22:09

1 Answers1

0

(Posted a solution on behalf of the question author, in order to move the answer to the answer space).

This was solved by not removing the system default version but instead installing other versions in different locations and then preferentially selecting them with the EXT_HINT flag for cmake.

The boost site suggests (via the release notes for 1.60) that a fix was made related to create_directories' return value. In any case, I was able to get the code to work "as written" by pointing to version 1.58 during compilation, but not to version 1.60, 1.65 or 1.72.

halfer
  • 19,824
  • 17
  • 99
  • 186