On 01/05/2017 11:17 AM, Tom Hughes wrote: > On 05/01/17 16:03, Stephen Gallagher wrote: > >> For many years, Fedora has supported multilib by carrying parallel-installable >> libraries in /usr/lib[64]. This was necessary for a very long time in order to >> support 32-bit applications running on a 64-bit deployment. However, in today's >> new container world, there is a whole new option. > > You may be living in a "new container world" but that doesn't mean the rest of > us (or our users) are. > By "new container world" I meant "a world where containers exist and can offer a complete 32-bit runtime" rather than a hacked-in multilib runtime. >> I'd like to propose that we consider moving away from our traditional approach >> to multilib in favor of recommending the use of a 32-bit container runtime when >> needed on a 64-bit host. > > On the face of it it sounds like a terrible idea but perhaps I have > misunderstood the consequences. > > Can you explain what this would actually mean for an average software developer > trying to build a 32 bit program? > > Take for example my day job where I'm developing a proprietary application on a > Fedora workstation. Now mostly I use a 64 bit build of the software but we have > a few databases we support where the vendor doesn't provide 64 bit libraries so > I have to use a 32 bit build. > > Would this mean I had to do some special dance to enter a container environment > in order to work with a 32 bit build rather than just telling our build scripts > to use "gcc -m32" when compiling? > Building of software shouldn't be changed at all in most cases. The main difference would be installation/deployment. The idea would be that instead of the 32-bit and 64-bit runtimes being installed directly in parallel on the base system, they would instead be installed into effectively a chroot with its own completely 32-bit runtime. In practical terms, this would be akin to installing it on a 32-bit VM, except without the overhead and a separate kernel. It gets a bit fuzzier when it has to interact with certain system services (see the "Open Questions" for some examples).
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
