Long story short, if we remove ugly Gentoo hacks python3.2+ libraries turn into upstream-expected 'libpython3.4m.so', and includedir into '/usr/include/python3.4m'. This ofc breaks boost hard because instead of obtaining the needed data from python, pkg-config or anything sane it just hardcodes nonsense defaults. Random distros end up throwing helluva random symlinks just to unbreak this nonsense and support their lack of sanity. Good news is that includedir is rather easy to workaround -- we can just pass it as part of 'using python' call. Sadly, we can't do the same for library and I can't find a way to fix it without patching the build system. In particular, changing version to '3.4m' doesn't help since boost 'normalizes' it, effectively changing it back to '3.4'. We need this fixed to stop diverging from upstream in Python. Any suggestions on how to handle this will be appreciated.
Oh, this can be reproduced by switching to the 'python-soabi-cleanup' branch of ::gentoo and upgrading Python(s).
Fedora patch: http://pkgs.fedoraproject.org/cgit/boost.git/tree/boost-1.57.0-python-abi_letters.patch
(In reply to Michał Górny from comment #2) > Fedora patch: > http://pkgs.fedoraproject.org/cgit/boost.git/tree/boost-1.57.0-python- > abi_letters.patch I am testing this patch right now.
*** Bug 567900 has been marked as a duplicate of this bug. ***
(In reply to Justin Lecher from comment #3) > (In reply to Michał Górny from comment #2) > > Fedora patch: > > http://pkgs.fedoraproject.org/cgit/boost.git/tree/boost-1.57.0-python- > > abi_letters.patch > > I am testing this patch right now. This patch makes boost-1.57.0 build for me too. Using dev-lang/python-2.7.11 and dev-lang/python-3.4.3-r5
Didn't I fix this already? I'm pretty sure I've committed some fix for it.
(In reply to Michał Górny from comment #6) > Didn't I fix this already? I'm pretty sure I've committed some fix for it. Does not appear so. Before applying this patch boost did not build with current unstable python
commit 04e5898847f506eef4e6d0c58ce21710e2671cee Author: Michał Górny <mgorny@gentoo.org> Date: Tue Nov 10 18:38:43 2015 dev-libs/boost: Work-around library rename due to ABIFLAGS Create a compatibility symlink to work-around Boost linking failures when Python library name contains ABIFLAGS. A proper fix would be preferable but the build system is convoluted and buggy, so a work-around is put in place instead.
(In reply to Michał Górny from comment #8) > commit 04e5898847f506eef4e6d0c58ce21710e2671cee > Author: Michał Górny <mgorny@gentoo.org> > Date: Tue Nov 10 18:38:43 2015 > > dev-libs/boost: Work-around library rename due to ABIFLAGS > > Create a compatibility symlink to work-around Boost linking failures > when Python library name contains ABIFLAGS. A proper fix would be > preferable but the build system is convoluted and buggy, so a > work-around is put in place instead. ahh, I changed 2 things. I added the patch and changed to boost-1.57 I guess I only had to up to 1.57 The patch seems to do no harm though.
Created attachment 419050 [details] boost-1.56.0-r2.ebuild with the same fixes as in the 1.57 and 1.58 ebuilds
I think it would be good if the same change is added to a boost-1.56.0 ebuild. Since that is the currently the only stable one and I'm forced to use it since libreoffice-bin depends on that version. I just added an ebuild that works for me with the same changes as in the ebuilds for the newer versions.
*** Bug 568058 has been marked as a duplicate of this bug. ***
Okay, workaround applied to all in-tree ebuilds and apropriate patches are merged upstream. I think we can close this.
