1 |
On Saturday 12 January 2008, Fabian Groffen wrote: |
2 |
> On 11-01-2008 21:52:08 -0500, Mike Frysinger wrote: |
3 |
> > On Tuesday 08 January 2008, Fabian Groffen wrote: |
4 |
> > > - sort out the 64-bits targets with their multilib-hell forced upon us |
5 |
> > |
6 |
> > dont know exactly what you're referring to, but multilib is completely |
7 |
> > optional. |
8 |
> |
9 |
> http://article.gmane.org/gmane.linux.gentoo.alt/3329 |
10 |
|
11 |
sorry, when i first read the multilib-hell, i assumed you meant the Gentoo |
12 |
pieces rather than the binutils/gcc pieces. |
13 |
|
14 |
i could post some corrections to the piece there, but in the end, they wouldnt |
15 |
get you to a final working solution. |
16 |
|
17 |
> Added to that that when I implemented the ldwrapper on amd64 (fedora) |
18 |
> linux I didn't fully understand the full multilib picture, some |
19 |
> decisions I made there now just feel plain wrong, especially given that |
20 |
> each distro seems to implement the multilib thing different (Gentoo: |
21 |
> /lib = native bits size, Fedora: /lib = 32-bits, Debian ...). |
22 |
> I didn't get it fully right in my post above though, because every |
23 |
> distro/os has a kernel configured in such a way that for a 64-bits |
24 |
> object, the search path points to the 64-bits host-specific lib paths. |
25 |
> So it seems that only binutils doesn't want to know about 64-bits |
26 |
> host-specific lib paths, and gcc takes actions to compensate that. |
27 |
|
28 |
i dont know why you keep saying "kernel" over and over when the kernel plays |
29 |
no role here whatsoever. if you want to keep things sane, i would say just |
30 |
follow the tool convention and any/all distro conventions be damned. |
31 |
|
32 |
longer term, i'm really not familiar with how the prefix stuff is architected, |
33 |
so i cant give much guidance unless i sat down and learned it. |
34 |
-mike |