1
votes

I'm working on a library that is statically linking our boost dependencies so that we do not have to worry about conflicting with users.

Our library statically links

  • date_time
  • system
  • thread
  • regex
  • filesystem
  • program options

We then have an executable that also needs program_options and links against it dynamically.

When we run the excutable we are getting a double free.

We could take the solution of not linking our code against program_options, which realistically we do not need to, but I want to know WHY this is happening and HOW to prevent it going forward.

Is the answer "don't link your library against boost statically"? If so then what kind of strategies exist to ensure that my boost and your boost play nice together? If the answer is "there are a few boost libraries which shouldn't be static" then is there a list?

1
How is your library distributed? Do you have any control over how users link and distribute the client application?Paul Floyd
This has nothing to do with static vs dynamic linking. You have a double-free bug in: "We then have an executable..." Like all bugs in your code you need to find and fix it. Start by looking for / removing all raw owning pointers and replacing them with smart pointers.Richard Critten
The static and dynamically linked libs can't interact. So the problem is you calling free twice.UKMonkey
We do not have control over how users link. We went with linking boost statically because we can't convince our customer to use a specific version. I've run this through valgrind and all of the errors appear in boost/glibc, not our libraries code We don't have raw pointers within our code or the executable.Mike K.
@MikeK. Did you ever get an answer to this? I'm facing this problem as well. It's 11 months later, so I'm hoping you worked something out.firebush

1 Answers

0
votes

I was able to address the double free issue by using GCC's -fvisibility=hidden when building boost.

For more information, see: