development packages and multilib

Callum Lerwick seg at haxxed.com
Thu Apr 23 21:19:57 UTC 2009


On Wed, 2009-04-22 at 14:48 -0500, Chris Adams wrote:
> Once upon a time, Callum Lerwick <seg at haxxed.com> said:
> > But _I_ _do_ _not_ _have_ _to_ _do_ _this_ _for_ _Win32_ _or_ _mipsel_.
> > Why is i386 special?
> 
> When you compile for Win32, you are using a cross-compiler environment.
> Everything about it is different; different includes, compilers,
> libraries, etc.

Same thing with multilib. Only difference is i386 and x86_64 are mashed
together in the same tree, with the exception of lib/lib64. (and the
i386/x86_64 gcc is mashed together, but that's an implementation
detail.)

This implementation was fundamentally flawed to begin with. But hey, how
could whoever came up with it have known at the time?

Years later, it's clear what's wrong. Turns out /usr/include is in fact
arch specific. And various people's config-foo dealies are Doing It
Wrong.

... And I've given solutions to both of those. What other problems are
there with multilib?

> Now, Linux/i386 could be set up that way on Linux/x86_64, but that would
> require rebuilding the development stack for cross-compilation
> (different compilers, development packages, etc.).  This is not the same
> as multilib (which allows i386 and x86_64 binaries to co-exist).

That's my whole point here. If we're having problems with multilib, it's
because multilib is not ENOUGH like cross compiling.

> Nobody is interested in putting that much work into that setup,
> especially when you can just use mock (since i386 binaries can run
> natively on x86_64).

Pimpin' ain't easy.

Is fixing it right any less painful than maintaining the current setup?

That's how this thread started. People bitching about what a pain
maintaining multilib is.

> What is wrong with using mock?

It's slow, awkward and completely un-neccessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090423/4e9bd371/attachment.sig>


More information about the fedora-devel-list mailing list