I’ve been meaning to write about the 32-bit emulation libraries for a while, with all the problems they come with, included a lot of security problems. The chance come now since last night solar pushed (not yet to the tree though) the new test version of the new emul-linux ebuilds.
The first problem to know of is that at the moment the whole of the set of emulation libraries is a collection of security bugs; I cannot even start to count how many issues there are but for sure there are two for PAM, the two that caused the recent stabilisation of 1.0.4 version. So if you need a system where you count security first, you should not use the multilib profile for AMD64 and the emul-linux libraries. You can still use it without emul-linux for stuff like grub, but that should be it; anything bringing in emul-linux will bring in security-impaired software.
On the other hand, thanks to Daniel’s work on 32-bit userland, it’s likely that building these libraries will start being less of a problem. Some of the fixes are already in, others will go in in time; I fixed Perl and Qt4 last night, the next step is to add a sub-profile for building those libraries.
There is more work that needs to be done though, for instance PulseAudio needs to have a way to disable the whole daemon part and just build the library used by software, which is what you want on both the 32-bit compatibility library list and for daemon-less clients (for instance when you want to just use a remote host to send audio to). These will require some changes in PulseAudio itself and will have, thus, to wait for the new release and probably the one afterwards. I could start working on it already (I would probably be able to get it to work before end of the day) but since I cannot even use it yet it doesn’t make much sense. The problem is that the latest test versions fail nastily on my system, and I was unable to ask Lennart about them, since he’s currently at BOSSA.
Hopefully, one day, the emul-linux libraries wouldn’t be needed at all, and instead we’d be building the packages, in either 32-bit or 64-bit mode, directly as needed. The true multilib support is, currently, one of the most important lacking features of Gentoo; on the other hand, it seems like that what gets discussed for implementation is stuff that has relatively little importance to users, and a lot of importance on “who is right” about implementation details.
Frankly, I really wish we were finally discussing a way to express the difference between same-ABI and any-ABI dependencies between packages, it would be really quite useful especially if the concept of ABI was expanded further to encompass also implementations like Ruby 1.8, Ruby 1.9, JRuby and so on so forth, so that we all could decide whether to build dev-ruby/ruby2ruby for one, the other, or all three together with its dependencies; or whether to install PulseAudio as 64-bit only or both 64-bit and 32-bit.
You may like to checkout the multilib overlay which aims to replace the emul-linux libraries.They have already converted most of the xlibs ebuilds to allow building both 32 and 64 bit libraries. For the first time I have been using my Radeon R500 card with wine thanks to multilib mesa 🙂
multilib FTL, multiarch FTW!!!
I certainly don’t want to build _everything_ in my system with multilib enabled!Proper, working multilib doesn’t mean building everything twice, but having proper dependency tracking between different ABIs, which means that, if I were to install a prebuilt x86 package using pulseaudio, it’ll ask me for pulseaudio, but never before that!
The idea behind the overlay isn’t to force every package to build both sets of libs. It includes an eclass that gives each package a lib32 USE flag. So, you would still get fine grained control.
Even if you were to check the USE deps with EAPI=2 still does not mean full multilib support since you cannot have different configurations for different ABIs.emul-linux is just a workaround until the proper multilib support is in Portage, that is what people should be spending time to fix rather than changing most of the workarounds around. Or discussing about SCM ebuilds.
First of all ,thanks for fixing qt4-build eclass :)You article was amazing (as always). It helped me clarify many things about multilib and pure 64bit support.Thanks for this post 🙂
While I would agree that multilib is important and it’s a big security problem, I disagree about the importance issue. You see, the major problem I see going forward with multilib is no one has come up with a formal proposal that shows how it all would work.We can talk all day long about how X feature is less important than Y feature and so X feature shouldn’t be attacked as a problem, but until there is a clear design, nothing will go forward. You could probably even do that as you don’t typically get involved with the SCM and related discussions these days.
Its actualy a bigger problem then only have support for 32bit/64bit abi deps in portage. Other arches has more ABI then x86:arm -> 2 (OABI, EABI)mips -> 4 (o32 n32 n64 eabi)and of course packages can build on one of them cannot build on other =)
Thomas, I’d love to work on fleshing out the requirements for proper multilib support, but I did already propose quite a few possible ways to handle that before, and each time the discussion was either non-present (because nobody cared about stuff that wasn’t implemented before by someone else) or ended up going for the bikeshed problem (how do we name the variable?).For once I’m not blaming _just_ Ciaran, I’m blaming _all_ the people involved because they seem just to argue over things that one implemented and not the other to make it a popularity contest of who’s better. They are just doing brain masturbation, rather than providing users with the features that are been left lingering in a limbo for years.And as alexxy points out, there are more than two ABIs; Gentoo/FreeBSD for x86 can actually handle two ABI (FreeBSD and Linux), and four on AMD64. So having proper multilib goes beyond supporting 32-bit builds of stuff.
Well, technically, you don’t need 32 bit libraries for 32 bit programs. The Intel 64 bit processors are capable of using 32 bit libraries with 64 bit programs and vise-versa. In fact, Intel’s own testing OS does this. They link 32 bit with 64 bit stuff so they didn’t need to re-write everything. The same can be done with regular user land programs, but I think some would need to be fixed to detect if it’s 32 or 64 bit data. Since most programs are open source, it should be possible to fix the broken ones. By fixed, I mean, that some programs might buffer overflow or something like that because they are expecting 32 bit only or the likes.This would lead to full integration of 32 and 64 bit apps and no silly multiple libs, one for 32 bit and one for 64 bit. That takes double the space and is really not needed on modern hardware.I think this solution should be looked at since it provides the best integration, the best cooperation, and the slimiest install possible. I think it would reduce the security risks as well.You can contact Intel about what I am saying or I believe their website has documents about working with 64 and 32 bit data. But, I know they do some pretty nifty tricks on their in house OS. It’s really cool stuff. I do know what I am talking about. 😉 And I fully believe this is the one true correct solution.