1 |
On Monday 19 October 2009 17:02:50 Thomas Sachau wrote: |
2 |
> Robin H. Johnson schrieb: |
3 |
> > On Sun, Oct 18, 2009 at 10:26:37PM -0400, Mike Frysinger wrote: |
4 |
> >> On Sunday 18 October 2009 14:49:09 Thomas Sachau wrote: |
5 |
> >>> Robin H. Johnson schrieb: |
6 |
> >>>> On Mon, Oct 12, 2009 at 04:50:23PM -0400, Mike Frysinger wrote: |
7 |
> >>>>> what exactly does this "lib32" do ? naming USE flags according to |
8 |
> >>>>> specific ABI implementations is a bad idea. you have to forget |
9 |
> >>>>> special casing anything to "lib32 vs lib64". amd64, while the most |
10 |
> >>>>> common, is hardly extensible. we must handle multiple ABIs which |
11 |
> >>>>> easily might have the same bitsize. |
12 |
> >>>> |
13 |
> >>>> The canonical example for this does still remain MIPS I believe. |
14 |
> >>>> |
15 |
> >>>> The most common ABIs in MIPS are: |
16 |
> >>>> o32, n32 - Both in Gentoo releases |
17 |
> >>>> n64 - Was experimentally done in Gentoo |
18 |
> >>>> (default-linux/mips/2007.1-dev/generic-be/n64) o64, eabi, meabi, nubi |
19 |
> >>>> - Not sure if they were were ever released in any way. |
20 |
> >>>> |
21 |
> >>>> Crossdev DOES support the full swath of these last I checked it. |
22 |
> >>> |
23 |
> >>> There is a difference between creating a toolchain and supporting all |
24 |
> >>> packages for that arch and every possible ABI you can crosscompile. |
25 |
> >>> |
26 |
> >>> Currently i only support amd64 since thats the only ARCH i know and |
27 |
> >>> have access to. If i get enough details to implement other ARCHes and |
28 |
> >>> some way to test it there, i might try it for those other ARCHes too. |
29 |
> >> |
30 |
> >> we're not asking you to implement support for these ABIs, just to keep |
31 |
> >> in mind that any implementation that does not scale and/or hardcodes to |
32 |
> >> a single set of ABIs isnt a proper solution |
33 |
> > |
34 |
> > My main objection thusfar is hardcoding the names as lib64/lib32. |
35 |
> > |
36 |
> > Is there any specific reason you're using the content of the |
37 |
> > LIBDIR_${ABI} variable? Maybe using the $ABI string as the USE flag |
38 |
> > would be better, in some form of USE_EXPAND manner (cannot use them raw |
39 |
> > as I believe we still have some code in the form of 'use $ARCH', which |
40 |
> > might not behave sanely if say both amd64 and x86 were set. |
41 |
> > |
42 |
> > Egs: |
43 |
> > multilib AMD64: |
44 |
> > USE="abi_x86 abi_amd64" |
45 |
> > |
46 |
> > Multilib PPC64: |
47 |
> > USE="abi_ppc abi_ppc64" |
48 |
> > |
49 |
> > Multilib MIPS (SGI hardware) |
50 |
> > USE="abi_n32 abi_n64" |
51 |
> > |
52 |
> > Possible valid multilib sets on MIPS are: |
53 |
> > [n32,n64] - at least one Gentoo system like this has been built. |
54 |
> > [o32,o64] |
55 |
> > [eabi,meabi] - docs fuzzy |
56 |
> > [nubi] |
57 |
> |
58 |
> I dont mind using some other string here. So those USE flags would be fine |
59 |
> for me. They could be USE_EXPANDed to e.g. for multilib amd64 ABI="x86 |
60 |
> amd64" |
61 |
> |
62 |
> Any other comment or suggestions on this part? |
63 |
|
64 |
what Robin has proposed makes sense to me |
65 |
-mike |