On 05/01/17 11:25 -0500, Stephen Gallagher wrote:
On 01/05/2017 11:17 AM, Tom Hughes wrote:
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.
I'm not sure how that's possible.
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.
Which changes how software is built, surely.
Tom's use case is where you simply invoke "gcc -m32" on the base
system and (assuming the relevant 32-bit versions of the libs are
present in /usr/lib) it Just Works.
If the 32-bit headers and libs aren't present on the base system then
you have to change how the software is built.
In practical terms, this would be akin to installing it on a 32-bit VM, except
without the overhead and a separate kernel.
Which definitely changes how software is built.
I'm sympathetic to the view that building in a pure-32-bit container
is probably ideologically better, but it's not how most of us are used
to working today. Building a 32-bit x86 application on an x86_64 host
is simple and doesn't involve containers.
Also, how would this work for something like GCC which wants to build
both 64-bit and 32-bit versions of runtime libraries, like libstdc++
and libgcc? If the base system doesn't have the 32-bit glibc libraries
present, how would GCC link the 32-bit libstdc++.so?
And as already mentioned, I don't know how this would affect Steam.
Please don't break Steam.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
