Dependency of 32bit pulsaudio. Reproducible: Always
Created attachment 361066 [details, diff] json-c-0.11.ebuild.patch
Reassigning to multilib as i am not that familiar with these eclasses yet.
Created attachment 363136 [details, diff] Alternative gx86 patch with working tests A little duplication of effort, but my version keeps FEATURES=test working.
Between the two patches, one thing that could be combined (improved in my patch) would be using INCLUDES=-I${S} for the tests, rather than symlinking the headers.
I've taken another route and added in-source build support to autotools-multilib. This allowed me to convert the ebuild with minimal changes. +*json-c-0.11-r1 (24 Nov 2013) + + 24 Nov 2013; Michał Górny <mgorny@gentoo.org> +json-c-0.11-r1.ebuild: + Enable multilib support, bug #488272. No blockers since it doesn't seem to collide with emul-linux (library name change?)
The json-c in emul-linux has different SONAME than converted one. Let's keep this open once we decide if we want to convert an older version as well, or just bump emul-linux.
(In reply to Michał Górny from comment #6) > The json-c in emul-linux has different SONAME than converted one. > > Let's keep this open once we decide if we want to convert an older version > as well, or just bump emul-linux. I don't think we need to convert older versions, this is a "classical" issue with old emul sets -> we need to wait until next round to get all libs in sync with native ones :/
So shall I replace json-c with the multilib dep when bumping emul-linux, or just keep old json-c there?
Are you talking about emul-linux ebuild when 32 bits USE is enabled? (the "metadata" usage of the ebuild?) In that case I think there is no problem on it pulling the newer version :/ (at least for this concrete case)
Added json-c to remove-native as well then.