I was attempting to build Chromium, and found out there were no 32-bit libraries for nss in the emul-linux-x86 packages. So I decided to make multilib ebuilds for it and it's dependencies. I'm probably doing something wrong here, so any suggestions would be very helpful.
Created attachment 176176 [details] nss-3.12.2_rc1-r1.ebuild dev-libs/nss multilib ebuild
Need to address real multilib issues before this can be done up. Not all users want/need a 32bit lib of nss.
Ditto, bug 252207 comment 5. Re-assigning.
packages shouldnt go doing multilib builds themselves. the options are: - integrate it into the mondo emul package amd64 maintains - do nothing and wait for proper multilib support to be implemented
(In reply to comment #4) > packages shouldnt go doing multilib builds themselves. the options are: > - integrate it into the mondo emul package amd64 maintains > - do nothing and wait for proper multilib support to be implemented > What do you mean by "proper multilib support"? bug 145737 ?
This currently blocks amd64 ebuild for chromium. Please add 32-bit nss libraries to one of emul-linux-x86 packages. If I can help with that, please let me know.
*** Bug 263189 has been marked as a duplicate of this bug. ***
www-client/chromium seems to work natively on amd64, or I am missing some kind of "black magic"? Is this still required by any package in the tree?
www-client/chromium has been a native amd64 application for a few months, and so no longer requires any 32-bit compatibility libraries. Still, it would be nice to have 32-bit nss in a multilib environment for other reasons.
Confirmed, www-client/chromium compiles natively on amd64. www-client/chromium-bin doesn't need emul- packages either, as upstream provides natively compiled packages for amd64.
(In reply to comment #9) > www-client/chromium has been a native amd64 application for a few months, and > so no longer requires any 32-bit compatibility libraries. Still, it would be > nice to have 32-bit nss in a multilib environment for other reasons. > Could you specify the reasons? Please take care that we try to keep emul packages not too huge since they are not as flexible as normal ebuilds (including nss would require to also include its dependencies, making emul package a bit bigger and more complicated to generate)
One example, although certainly an edge case, is building a 32-bit copy of Chromium for testing with the Chromium OS, which necessarily builds in a 32-bit chroot and uses a 32-bit kernel. There are likely other reasons, though.
OK, this is already needed by adobe-flash, then, I will try to get them into if possible I also use this bug for nss, nspr and sqlite since they are really related
*** Bug 252207 has been marked as a duplicate of this bug. ***
*** Bug 252218 has been marked as a duplicate of this bug. ***
*** Bug 298666 has been marked as a duplicate of this bug. ***
In new set
