1

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?

Mike K.
  • 33
  • 1
  • 2
  • How is your library distributed? Do you have any control over how users link and distribute the client application? – Paul Floyd Jan 15 '18 at 13:35
  • 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 Jan 15 '18 at 13:35
  • The static and dynamically linked libs can't interact. So the problem is you calling free twice. – UKMonkey Jan 15 '18 at 13:36
  • 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. Jan 15 '18 at 14:01
  • @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 Dec 17 '18 at 15:55
  • I believe we opted to not link the shared object against boost po since mucking with visibility didn't solve our issues. – Mike K. Dec 18 '18 at 16:47

1 Answers1

0

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

For more information, see:

firebush
  • 5,180
  • 4
  • 34
  • 45