On Tue, May 11, 2010 at 5:13 PM, Anthony Foglia
We are trying to link boost program options both statically and dynamically in an executable but when the executable finishes, it glibc reports a "double free or corruption" error.
The odd linking arises because we have a common library for our project with some modifications to program options (in particular a parser with built-in help and version options), but our executable code still refers to program options directly (both because it needs to use functions and classes from program options, and because the code hasn't been updated to use our custom parser.)
We are linking dynamically to the system-wide program options library, but our utility library is built and linked to statically.
(Our build system is boost-build, which determines the linker line.)
Should such a linking be possible? Our workaround is to force all linking to program options to be static, which I think I've figured out.
As far as I know (which should be 'enough'), for libraries like that, any mixing of static and dynamic linking *will* break. The only way to work around it is for the main application to be static, but have the other libraries dynamically link to the static version in the main application, and *not* to the system library, that can be done, but it requires a bit of working around.