DevHeads.net

Proposal: Rethink Fedora multilib support

# Overview

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.

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.

## Advantages

* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.

* Less duplication of content in the mirror networks.

* It will be simpler to create module content without having to reimplement all
the multilib hacks of above. This is directly relevant to the Base Runtime
module, whose prototype is today intentionally limited to the primary
architecture (no multilib).

* Requires us to maintain and keep up-to-date the 32-bit container base images.

## Disadvantages

* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.

* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.

* Requires us to maintain and keep up-to-date the 32-bit container base images.
(Yes, this is both an advantage and disadvantage.)

## Open Questions (non-exhaustive):

* Can SSSD and systemd's 32-bit name-service modules work from within a
container, talking to their host's service? Without that, 32-bit containers
won't be able to resolve users, groups or hostnames.

* Can we have 32-bit containers communicate with other local system APIs such as
D-BUS on the host?

* Do we need to care about 32-bit GUI applications on a 64-bit system? Should we
decide that flatpak is the official answer for such cases?

Comments

Re: Proposal: Rethink Fedora multilib support

By Mark Wielaard at 01/11/2017 - 11:09

On Thu, 2017-01-05 at 11:03 -0500, Stephen Gallagher wrote:
I think this is missing the developer story. I maintain a couple of
tools that currently need to handle 32-on-64-bit setups and it is a bit
of a pain. So getting rid of multilib certainly would make my life
easier. But some of those tools really do work better because they are
64-bit themselves but target 32-bit applications/libraries. It means
they can use the full 64-bit address space while reading/writing 32-bit
files/datastructures. I believe gcc and binutils/ld are in the same
category. Some applications targeting 32-bit architectures are so big
that you need 64-bit tools to just build them. Maybe this is a small
enough development story that it doesn't really matter. But it would be
good to know if developers are comfortable with a pure/native 32bit-only
development toolchain.

Thanks,

Mark

Re: Proposal: Rethink Fedora multilib support

By drago01 at 01/06/2017 - 02:02

There are still a lot of 32bit software out there. In stead of having it
just work you are asking users to fiddle around with hacks / jumping
through hoops.

So your proposal would cause way more harm than good.

Re: Proposal: Rethink Fedora multilib support

By Pavel Raiskup at 01/05/2017 - 21:32

I'm wholeheartedly against this. I also view personally containers *just*
as a thing to solve subset of real-world problems, but not a army knife
for everything. IOW, enforcing users to use containers instead of
multilib feature looks a bit hostile.

Have other distros already done this movement? I'm almost sure we
shouldn't pioneer this.

IMO: multilib && Modularization efforts && containerization efforts
shouldn't collide.

More in-line comments ...

On Thursday, January 5, 2017 11:03:50 AM CET Stephen Gallagher wrote:
If that's a real issue, we should avoid working on hacks, and rather
invent a new way to _declare_ some (sub)package is designed to be
multilib, I filed this:
<a href="https://pagure.io/pungi/issue/500" title="https://pagure.io/pungi/issue/500">https://pagure.io/pungi/issue/500</a>

That's not really duplication to me.

What's the reason to not have multilib in Base Runtime? Is that because
it is hard to experiment with multilib in copr (rhbz#1393664) or what
hacks are you referring to? The point of this remark is that there should
be a way to minimize hacks.

This would be pros, but we should probably have 32-bit container anyways..

.. user apps -> this looks like absolute showstopper IMO.

Even though there are also third-party package providers like skype --
where I would personally appreciate we either forced them to move to
container or provide x86_64 packages (or if there was really sufficient
open source alternative to make them obsolete)..
But I'm afraid such third party would rather drop Fedora support, which
would be bad especially for us..

Pavel

Re: Proposal: Rethink Fedora multilib support

By King InuYasha at 01/05/2017 - 17:08

On Thu, Jan 5, 2017 at 11:03 AM, Stephen Gallagher < ... at redhat dot com> wrote:
I'll be totally frank and say this entire proposal is garbage. There
is not a reasonable way this proposal is workable. It breaks the world
because it expects that you can completely segregate applications,
which you can't. It also expects that applications can be
containerized, which there are lot of cases where you can't. And it
also completely annihilates upgrade paths and user expectations on
having things like Wine, Steam, and other common applications to work.

If we're considering rethinking multilib, I'd be more inclined to see
if we could have multi-platform libdirs like how Debian does (though
they call them "multi-arch" libdirs). This proposed approach is
essentially broken by design because it implies that applications
should be segregated. I fundamentally disagree with this, because
there are many legitimate reasons to be able to have programs that
work together that cross architectures/platforms.

Please don't do this.

Re: Proposal: Rethink Fedora multilib support

By Nicholas Miell at 01/05/2017 - 16:44

On 01/05/2017 08:03 AM, Stephen Gallagher wrote:
All of my 32-bit software is installed in $HOME/.local/share/Steam, I
take it that under this proposal it would immediately stop working upon
upgrading Fedora and never work again?

Re: Proposal: Rethink Fedora multilib support

By Dennis Gilmore at 01/05/2017 - 13:58

On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote:
Dennis

Re: Proposal: Rethink Fedora multilib support

By Dan =?ISO-8859-... at 01/05/2017 - 14:55

On Thu, 05 Jan 2017 11:58:06 -0600

exactly, such solution should deliver the same user experience

Dan

Re: Proposal: Rethink Fedora multilib support

By Josh Boyer at 01/05/2017 - 14:35

On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore < ... at ausil dot us> wrote:
Multilib exists on non-x86 architectures. Should this proposal gain
traction, we need to consider the implications to those architectures.

josh

Re: Proposal: Rethink Fedora multilib support

By Dennis Gilmore at 01/05/2017 - 14:42

On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote:
Dennis

Re: Proposal: Rethink Fedora multilib support

By Josh Boyer at 01/05/2017 - 14:59

On Thu, Jan 5, 2017 at 1:42 PM, Dennis Gilmore < ... at ausil dot us> wrote:
I stand corrected. For some reason I thought it still existed on
ppc64, but that is clearly not the case.

josh

Re: Proposal: Rethink Fedora multilib support

By Daniel P. Berrange at 01/05/2017 - 13:09

On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote:
More work for the end user to keep their systems updated. Containers in
general are a retrograde step in this area, since instead of being able
todo a simple "dnf update" on the host and have everything updated, you
have to do "dnf update" and then figure out how to update each individual
container. Even if we assume the 32-bit container base image lets you use
dnf normally, this change has at least added an extra step for users
as they have to upgrade their 64-bit and 32-bit container via separate
"dnf update" command invokations.

Regards,
Daniel

Re: Proposal: Rethink Fedora multilib support

By Petr Sabata at 01/05/2017 - 13:20

On Thu, Jan 05, 2017 at 05:09:59PM +0000, Daniel P. Berrange wrote:
I think we're only considering this for the modular composes,
where containers would be just instance of modules, managed
by the base system, presumably through something as simple as
"dnf update".

Plenty of assumptions but I believe that's the plan.

P

Re: Proposal: Rethink Fedora multilib support

By Thorsten Leemhuis at 01/05/2017 - 12:38

Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
Just wondering: Why don't we switch to a multilib/multiarch solution
similar to the one that Debian/Ubuntu uses? They put libs in directories
like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
(<a href="https://wiki.debian.org/Multiarch/Implementation" title="https://wiki.debian.org/Multiarch/Implementation">https://wiki.debian.org/Multiarch/Implementation</a>
<a href="https://wiki.ubuntu.com/MultiarchSpec" title="https://wiki.ubuntu.com/MultiarchSpec">https://wiki.ubuntu.com/MultiarchSpec</a> ). If we'd switch to a similar
solution a new (de facto) standard might evolve and in the end nobody
would have to deal with hacks any more, because all major distros would
put libs in the same directories. Iirc their model has benefits for
cross-compilation, too.

Cu, knurd

Re: Proposal: Rethink Fedora multilib support

By Richard W.M. Jones at 01/07/2017 - 18:53

On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote:
IMHO this is a much better idea. Also being closer to Debian means
less hacking required to build GCC (or at least, it's the same hacking
as Debian needs). Also we can kill /usr/lib64 finally.

Rich.

Re: Proposal: Rethink Fedora multilib support

By Jonathan Wakely at 01/11/2017 - 10:25

On 07/01/17 22:53 +0000, Richard W.M. Jones wrote:
How's that? To build GCC on Debian needs an entire new configure
option that isn't needed at all on Fedora: --enable-multiarch

There's *more* hacking needed to build GCC on Debian. So yes, if we
copy them we'll need the same hacking as Debian needs, but that's not
less hacking than we have now.

Re: Proposal: Rethink Fedora multilib support

By =?ISO-8859-1?Q?... at 01/11/2017 - 12:19

Dne 11.1.2017 v 15:25 Jonathan Wakely napsal(a):
And yet the configuration is wrong and does not support the current
needs of packages on Fedora:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=979403" title="https://bugzilla.redhat.com/show_bug.cgi?id=979403">https://bugzilla.redhat.com/show_bug.cgi?id=979403</a>

Vít

Re: Proposal: Rethink Fedora multilib support

By King InuYasha at 01/07/2017 - 18:55

On Sat, Jan 7, 2017 at 5:53 PM, Richard W.M. Jones < ... at redhat dot com> wrote:
It improves the situation, but /usr/lib64 will be with us for a long
time to come...

Re: Proposal: Rethink Fedora multilib support

By Tom Hughes at 01/05/2017 - 12:42

On 05/01/17 16:38, Thorsten Leemhuis wrote:
That's exactly what I thought was about to be proposed when I saw the
subject of the email and I got excited for about 30 seconds until I read
the body ;-)

Tom

Re: Proposal: Rethink Fedora multilib support

By Stephen Gallagher at 01/05/2017 - 12:56

On 01/05/2017 11:42 AM, Tom Hughes wrote:
If we end up staying with a multilib approach, there's certainly a lot of merit
to developing a cross-distribution standard.

However, it still doesn't solve the problem that we have today, which is that we
have to do a lot of hacky shuffling around of packages in order to take packages
built in i686 and drop them onto the x86_64 repository.

It might be different if we could build 32-bit sub-packages in the 64-bit mock
environment, but the tools are *really* not equipped to handle that today (in
particular because Fedora doesn't do cross-compilation; we just spin up a
builder of the actual hardware it should run on.)

Re: Proposal: Rethink Fedora multilib support

By Kevin Kofler at 01/05/2017 - 14:51

Stephen Gallagher wrote:
Then just have the users enable the 32-bit repository if they want 32-bit
packages. IMHO, that would make sense.

Forcing everybody who needs multilib to use containers, on the other hand,
is a very bad idea.

Kevin Kofler

Re: Proposal: Rethink Fedora multilib support

By Daniel P. Berrange at 01/05/2017 - 13:05

On Thu, Jan 05, 2017 at 11:56:28AM -0500, Stephen Gallagher wrote:
NB, Fedora does do cross-compilation in some places - many of the QEMU
firmware blobs are cross-compiled, as is the Mingw32/64 toolchain.

Regards,
Daniel

Re: Proposal: Rethink Fedora multilib support

By Dan =?ISO-8859-... at 01/05/2017 - 12:52

On Thu, 5 Jan 2017 16:42:25 +0000

couldn't you add on a pure 64-bit system a pure 32-bit repo (with lower
priority) and wouldn't things still work?

Dan

Re: Proposal: Rethink Fedora multilib support

By Christian Fredr... at 01/05/2017 - 12:28

While most desktop applications have migrated to 64 bit at this point there are
still many that hasn't. Steam for instance is still 32-bit afaict. So doing a clean
cutover like this feel a bit to drastic to me and I am not sure we have the market power
to 'force' vendors to quickly migrate to containers.

Christian

Re: Proposal: Rethink Fedora multilib support

By Ben Rosser at 01/05/2017 - 14:11

On Thu, Jan 5, 2017 at 11:28 AM, Christian Schaller < ... at redhat dot com>
wrote:

Speaking from an end-user perspective, I actually really like the way
multilib on Fedora is currently implemented. All I need to do to get a
32-bit application-- be it some Windows application under wine, some
proprietary application like Steam, etc.-- to work is to install the 32-bit
packages via yum/dnf, and then things Just Work.

I understand that from a building-the-distribution perspective the way this
is done currently is kind of a hack, but I can't help but notice that the
*only* benefits to this proposal would be that it makes building the
distribution easier. There are no proposed benefits for our users beyond
breaking the way things currently work with probably no upgrade path. And
whether we like it or not, users, myself included, install nonfree software
like Steam on systems and generally expect it to continue working from
release to release.

Ben Rosser

Re: Proposal: Rethink Fedora multilib support

By Matthew Miller at 01/05/2017 - 12:26

On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote:
The main thing that comes to mind is Wine. Perhaps PlayOnLinux
could be made into a Flatpak?

Re: Proposal: Rethink Fedora multilib support

By Tom Hughes at 01/05/2017 - 12:17

You may be living in a "new container world" but that doesn't mean the
rest of us (or our users) are.

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?

Tom

Re: Proposal: Rethink Fedora multilib support

By Stephen Gallagher at 01/05/2017 - 12:25

On 01/05/2017 11:17 AM, Tom Hughes wrote:
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.

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).

Re: Proposal: Rethink Fedora multilib support

By Josh Boyer at 01/05/2017 - 14:26

On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher < ... at redhat dot com> wrote:
You just described a fundamental change to how people would need to
build 32-bit applications locally. They don't have to install a
VM/chroot to do that today, they would in a containerized multilib
solution. I don't think it's fair to claim "Building of software
shouldn't be changed at all in most cases" with this proposal.

Remember, not all software is built in mock or even as RPMs. End user
software developers will be impacted by the removal of existing
multilib.

josh

Re: Proposal: Rethink Fedora multilib support

By Daniel J Walsh at 01/05/2017 - 14:31

On 01/05/2017 01:26 PM, Josh Boyer wrote:

Re: Proposal: Rethink Fedora multilib support

By Richard W.M. Jones at 01/07/2017 - 19:00

On Thu, Jan 05, 2017 at 01:31:19PM -0500, Daniel J Walsh wrote:
A 10 year horizon is also the timeframe proposed for introducing
RISC-V 128 bit hardware (128 bit emulation is already available,
although unless you enjoy writing machine code by hand it's not much
use right now), so we'll have potentially 3 different arches to
target.

Rich.

Re: Proposal: Rethink Fedora multilib support

By Josh Boyer at 01/05/2017 - 14:40

On Thu, Jan 5, 2017 at 1:31 PM, Daniel J Walsh < ... at redhat dot com> wrote:
I'm not suggesting we shouldn't change our multilib strategy. I'm
saying we can't change it can claim that it won't impact end users.
That is all.

josh

Re: Proposal: Rethink Fedora multilib support

By Stephen John Smoogen at 01/05/2017 - 14:36

On 5 January 2017 at 13:31, Daniel J Walsh < ... at redhat dot com> wrote:
Yes. We will. And in 10 years from now the inevitable backlash against
containers because they aren't new and nifty and had all these warts
that come from real life will be in full swing. [This doesn't mean
that containers will go away any more than they were completely new in
the first place but ideas that Multics (and other OS's had) in the
1960/70's.] This is how software goes.

Re: Proposal: Rethink Fedora multilib support

By Daniel J Walsh at 01/05/2017 - 14:48

On 01/05/2017 01:36 PM, Stephen John Smoogen wrote:

Re: Proposal: Rethink Fedora multilib support

By M. Edward (Ed) ... at 01/05/2017 - 15:11

Well, I'm retired *now* and I'm still a Fedora end-user. ;-)

But seriously ... aren't there plenty of distros that support older 32-bit
hardware ... enough so that Fedora can draw a line in the sand and say,
Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other
stuff and run it in a Debian container?

And speaking of Wine, how come the Windows 10 Linux subsystem only runs
Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows machine?

Fedora Linux subsystem on Windows machine

By =?ISO-8859-1?Q?... at 01/06/2017 - 05:01

Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
Just FYI:

<a href="http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora" title="http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora">http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora</a>

Vít

Re: Fedora Linux subsystem on Windows machine

By =?utf-8?b?TWFyd... at 01/06/2017 - 05:03

On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch < ... at redhat dot com>
wrote:

I think that doesn't work anymore. But there's this project that should
work now [0], while being more user friendly and versatile.

[0] <a href="https://github.com/RoliSoft/WSL-Distribution-Switcher" title="https://github.com/RoliSoft/WSL-Distribution-Switcher">https://github.com/RoliSoft/WSL-Distribution-Switcher</a>

Re: Fedora Linux subsystem on Windows machine

By =?ISO-8859-1?Q?... at 01/06/2017 - 05:46

Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
Thanks for pointing this out. I knew I saw something more advanced, but
already forgot what it was ;) I am not windows user mysefl ...

Vít

Re: Proposal: Rethink Fedora multilib support

By Chris Adams at 01/05/2017 - 15:30

Once upon a time, M. Edward (Ed) Borasky < ... at znmeb dot net> said:
If I have to run Debian to use the software I need/want (for example, as
others already mentioned in this thread, I use Teamviewer and Steam),
then I'm not going to run Fedora as well.

It isn't about 32-bit hardware, it is about 32-bit software. I'd love
to be running a pure open source system, but in the real world, I can't.

Re: Proposal: Rethink Fedora multilib support

By Josh Boyer at 01/05/2017 - 15:15

On Thu, Jan 5, 2017 at 2:11 PM, M. Edward (Ed) Borasky < ... at znmeb dot net> wrote:
Um... no. Why would we drop the other alternative architectures that
have worked diligently to release in lock-step with x86_64? I have a
fundamental disagreement with that suggestion.

I think you should start another thread about that topic.

josh

Re: Proposal: Rethink Fedora multilib support

By Florian Weimer at 01/05/2017 - 13:27

On 01/05/2017 05:25 PM, Stephen Gallagher wrote:
Downstream doesn't provide these chroots for the 32-bit variants at
present, so I expect that most 32-bit build environments use the -m32
(or -m31) approach there. This is a very significant change. (Of
course, an even more significant change is just around the corner:
32-bit architectures are almost out of the picture anyway.)

Or you end up cross-compiling, with some path/sysroot hackery. Even if
the kernel could theoretically run the built binaries, all the userspace
libraries are still missing, so it would effectively be cross-compilation.

Thanks,
Florian

Re: Proposal: Rethink Fedora multilib support

By Jonathan Wakely at 01/05/2017 - 13:02

On 05/01/17 11:25 -0500, Stephen Gallagher wrote:
I'm not sure how that's possible.

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.

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.

Re: Proposal: Rethink Fedora multilib support

By Randy Barlow at 01/05/2017 - 15:42

On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote:
Containers also change the way software must be written in some cases,
since they expect there to be one main process and don't expect that
main process to interact with other "main" processes on the system.
There are some program architectures that aren't well suited to be run
in containers since containers expect programs to work in specific
ways. I don't think they are general enough to cover all use cases.

I also expect that users will not appreciate being forced to use
containers if they want to keep being able to do things they can do
today. Offering it to them as an option rather than the only solution
is probably a friendlier approach.

Re: Proposal: Rethink Fedora multilib support

By Jonathan Wakely at 01/06/2017 - 08:33

On 05/01/17 14:42 -0500, Randy Barlow wrote:

That would certainly be a problem if the proposal was to run each
32-bit application in its own container environment, but I think the
suggestion is to have a single 32-bit container used by all 32-bit
software. With that approach all the 32-bit software would be able to
interact with the rest of the 32-bit system, there wouldn't be
segregation between them.

But we would need to consider how a 32-bit application starts other
programs via things like xdg-open. Would you have to have a 32-bit
browser installed so that you could click on links in 32-bit
applications? Would xdg-utils have to be installed on the system
twice, once in the 64-bit host and once in the 32-bit container? And
install things like Firefox and image viewers twice?

Re: Proposal: Rethink Fedora multilib support

By Stephen Gallagher at 01/06/2017 - 09:06

On 01/06/2017 07:33 AM, Jonathan Wakely wrote:

Yes, I was unclear about this, but that was where I was going with it. A single
32-bit container whose purpose was to share the 32-bit runtime. That being said,
the counter-proposal of figuring out how to keep the layout the same as today
but keeping the content in separate repositories is compelling and I'm
investigating that further.

Very good questions and I don't have all the answers right now, but again, I
think the "separate repository" solution might be closer, as the end result
should keep things in the same hierarchy.

Re: Proposal: Rethink Fedora multilib support

By Bastien Nocera at 01/06/2017 - 08:48

I wonder how that would work when 1) you need access outside the sandbox
(say to play audio through PulseAudio, which needs an ALSA 32-bit plugin),
or 2) the 32-bit binary is a plugin (remember 32-bit Flash inside Firefox
with the nppluginwrapper?).

Re: Proposal: Rethink Fedora multilib support

By Andrew Lutomirski at 01/05/2017 - 13:18

On Jan 5, 2017 9:03 AM, "Jonathan Wakely" < ... at fedoraproject dot org>
wrote:.

The main
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.

The Linux kernel needs gcc -m32 to work for freestanding programs.

Linux's x86 test suite likes normal glibc programs built with gcc -m32 to
work.

--Andy

Re: Proposal: Rethink Fedora multilib support

By Tom Hughes at 01/05/2017 - 12:41

Right, but even if manages to compile and link (it somehow finds glibc
inside that chroot?) what happens if I run the program? Has the linker
automatically added a run path to it that points at the chroot so it can
find libc?

Tom

Re: Proposal: Rethink Fedora multilib support

By Michael Cronenworth at 01/05/2017 - 12:15

On 01/05/2017 10:03 AM, Stephen Gallagher wrote:
I care. What impact would this have on Wine? If users are unable to use 32-bit
Windows apps, which are still a nice majority of apps, they'll quickly abandon
Fedora. Eventually that majority will get switched, but I don't see it happening for
at least 2-3 more years.

Re: Proposal: Rethink Fedora multilib support

By Stephen Gallagher at 01/05/2017 - 12:19

On 01/05/2017 11:15 AM, Michael Cronenworth wrote:
Sorry, using the word "care" there was poorly phrased. I meant more like "are
there 32-bit GUI applications that are very important and couldn't be made to
fit this new approach?". Wine is an interesting example I had not considered.

Are we certain that it couldn't be run from within a container, though? Possibly
via a wrapper?