On Wed, 2009-04-22 at 14:48 -0500, Chris Adams wrote: > Once upon a time, Callum Lerwick <seg@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
