After upgrading to dev-libs/boost-1.60.0 and rebuilding app-office/akonadi-server, Akonadi fails to start. Attempting to use the `akonadictl` tool gives an error, even for trivial command lines: $ akonadictl --help Failed to parse command line arguments: character conversion failed Run 'akonadictl --help' to obtain a list of valid command line arguments. Akonadi functionality is restored after downgrading to dev-libs/boost-1.58.0 and rebuilding app-office/akonadi-server again. Suggest adding a DEPEND="!=dev-libs/boost-1.60.0*" in app-office/akonadi-server. Problem appears in both app-office/akonadi-server-1.13.0-r2 and app-office/akonadi-server-1.13.1_pre20160203-r1.
Same here - downgrading (and therefore, recompiling all boost related packages such as libreoffice) boost to 1.58 make akonadi work again.
`akonadictl --help` works fine for me... boost 1.60 and app-office/akonadi-server-1.13.1_pre20160203-r1. all build w/ gcc 5.3.0.
I don't know how Alex Turbov (Comment 2) gets it to work. Akonadi fails again with Boost 1.61. $ akonadictl --help Failed to parse command line arguments: character conversion failed Run 'akonadictl --help' to obtain a list of valid command line arguments. Why can't Boost be slotted?
Slotting Boost would amount to a massive undertaking, as you have to avoid any one application bringing in libraries linked with different versions, as boost has a very brittle ABI. While I feel your pain, if you believe you are up to the task, you can try slotting it yourself. I am not aware of any distribution doing such things.
Can not confirm that runtime fails with dev-libs/boost-1.61.0
I discovered why this was failing after several hours of debugging in GDB and scratching my head as to why certain methods were being invoked when the caller was actually trying to invoke a different method. It seemed to be a violation of the One-Definition Rule, as the virtual function table entries seemed to be shifted down one function from what they should have been. As it turns out, this is exactly what was happening. Akonadi was being compiled with outdated Boost headers. Evidently CMake's FindBoost module prefers versioned include directory names over the system default. On my system, I had an orphaned "/usr/include/boost-1_51" directory with an apparently complete copy of the Boost include files for Boost 1.51. Akonadi's CMake run was selecting this directory for the include path rather than the system default path (/usr/include) where Boost 1.61's headers are installed. I do not know why /usr/include/boost-1_51 was not removed when I uninstalled Boost 1.51, but as no packages were claiming it now, I blew it away. Now the Akonadi build includes the correct Boost headers, and the failure at runtime is gone.
