| 1 |
On 14-06-2013 13:40:48 -0700, gmt@×××××.us wrote: |
| 2 |
> Anyhow, I’m wondering, is there somebody out there who knows what is behind |
| 3 |
> the decision to mask multilib in prefix-portage (or made it themselves), and |
| 4 |
> what it would take to fix it? By any chance, does the limitation pertain to |
| 5 |
> mostly to gcc-config and the special prefix magic that happens in the |
| 6 |
> dynamically generated gcc wrappers? |
| 7 |
|
| 8 |
multilib is inherently broken as a full system. The |
| 9 |
compiler/linker/libc/kernel should be to be able to build/run both, but |
| 10 |
for Prefix, you better bootstrap two prefixes. This has to do with |
| 11 |
libraries and executables not being multilib (but rather two different |
| 12 |
versions) and the mess that comes out of having them coexist next to |
| 13 |
each other properly. |
| 14 |
|
| 15 |
Honestly, the fat file approach of Mach-O (say, OSX) really is the only |
| 16 |
thing that works sanely here given that the packager (Apple in this |
| 17 |
case) really made sure it works out all fine. If you wonder why that |
| 18 |
approach works so well, then ask yourself why we have all this lib, |
| 19 |
lib32, lib64, lib32o, lib32n, lib/64, lib/sparcv9, lib/amd64, etc. etc. |
| 20 |
and basically only binaries of one type. |
| 21 |
|
| 22 |
Fabian |
| 23 |
|
| 24 |
-- |
| 25 |
Fabian Groffen |
| 26 |
Gentoo on a different level |
Archives