With recent changed in "multilib" USE value with multilib profiles I noticed that app-emulation/emul-linux-x86-compat has a really strange way of handling multilib stuff coming from sys-libs/libstdc++-v3. That emul package only contains 32bits libs from sys-libs/libstdc++-v3 and sys-libs/lib-compat. For some reason, that collides with sys-libs/libstdc++-v3[multilib] itself for ages because that package also provides 32 bits libs, then, we are doing this ugliness for a long long time: src_prepare() { emul-linux-x86_src_prepare if has_multilib_profile ; then rm -rf "${S}/usr/lib32/libstdc++.so.5.0.7" \ "${S}/usr/lib32/libstdc++.so.5" || die fi } That should probably be changed to be done depending on "multilib" USE instead of profile but... I don't understand why libstdc++ wasn't dropped long ago from this "compat" emul set package. Maybe the way to go would be to migrate sys-libs/lib-compat and sys-libs/libstdc++-v3 to new multilib eclasses and kill this emul package :/ What do you think?
Latest emul package now relies on "multilib" USE Reviewing the two packages provided in app-emulation/emul-linux-x86-compat: sys-libs/lib-compat -> it's not keyworded on amd64... but it's pretty simple: src_install() { if use x86 ; then into / dolib.so ld-linux.so.1* rm -f ld-linux.so.1* fi into /usr dolib.so *.so* } Maybe those libs could also be installed in amd64 && multilib sys-libs/libstdc++-v3 -> looks like it merged with multilib USE enabled is already replacing the libs pulled by emul package
CCing lib-compat maintainers too
A few notes: 1. sys-libs/libstdc++-v3 doesn't even compile for me. I don't know if it's worth fixing, 2. since lib-compat is binary as well, i see no point in having two packages install the same binary files. i'd go for making lib-compat compatible with amd64, 3. all of it is terrible and vulnerable, and so on. If we'd like to be lazy, I wouldn't mind masking it all for removal.
(In reply to Michał Górny from comment #3) > A few notes: > > 1. sys-libs/libstdc++-v3 doesn't even compile for me. I don't know if it's > worth fixing, > > 2. since lib-compat is binary as well, i see no point in having two packages > install the same binary files. i'd go for making lib-compat compatible with > amd64, > > 3. all of it is terrible and vulnerable, and so on. If we'd like to be lazy, > I wouldn't mind masking it all for removal. sys-libs/libstdc++-v3 compiles just fine for me. You may have some strange CFLAGS that GCC 3.3 (really!) doesn't like. I at least still need the 32-bit libstdc++.so.5 that libstdc++-v3[multilib] provides because some old binary-only games that will never be updated depend on it.
+*lib-compat-1.4.2-r1 (26 Jun 2014) + + 26 Jun 2014; Michał Górny <mgorny@gentoo.org> +lib-compat-1.4.2-r1.ebuild: + Support being installed on amd64. Since app-emulation/emul-linux-x86-compat + installs fundamentally the same files, there is no point having both. Bug + #506226. +*emul-linux-x86-compat-20140508-r1 (26 Jun 2014) + + 26 Jun 2014; Michał Górny <mgorny@gentoo.org> + +emul-linux-x86-compat-20140508-r1.ebuild: + Satisfy the dependencies using sys-libs/libstdc++-v3 and sys-libs/lib-compat, + rather than bundling them. Bug #506226.
