On Wed, 2009-04-22 at 14:48 -0500, Chris Adams wrote:
Once upon a time, Callum Lerwick <seg(a)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,
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
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
... 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
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.