On Tue, Oct 11, 2011 at 10:03 PM, Michael LIAO <michael.hl...@gmail.com> wrote: > On Tue, Oct 11, 2011 at 9:21 PM, Mike Frysinger <vap...@gentoo.org> wrote: >> On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote: >>> On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vap...@gentoo.org> wrote: >>> > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: >>> >> The current scheme documented on website >>> >> (https://sites.google.com/site/x32abi/) uses the existing triplet but >>> >> specify x32 ABI through compiler/linker options. It works for most >>> >> compilers aware of that, but how other tools not handling >>> >> compiler/linker options knows the current build is targeted on a >>> >> different environment? >>> > >>> > the mips people have been using a single tuple for multiple abis (n32 and >>> > n64), and it doesn't appear to have been a blocker for them ... >>> >>> That's not true, at least to build glibc, you can use >>> 'mips64-linux-gnuabi64' to specify a n64 build and >>> ''mips64-linux-gnuabin32' for a n32 build without specifying compiler >>> option explicitly. I just figured this out from mips ports of glibc >>> from >>> http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure, >>> where both compiler option and triplet are checked and triplet is >>> preferred if they are not match. >> >> while it is true glibc has this code, it doesn't make my statements >> incorrect: >> a single tuple works just fine with mips for multiple ABIs. if you look at >> other projects like gcc, it doesn't check this field at all. so you're still >> right where you started: you still haven't shown any cases which necessitate >> a >> dedicated tuple. > > That's why the proposed new triplet won't break existing packages as, > if they are compliant to autoconf, they should check that field with > 'gnu*' or just ignore it instead of an exact matching. > > I am not asking a dedicated triplet for x32 to be used exclusively for > x32 package build. I am asking additional triplet with enough details > of execution environment (ABI definitely a necessary detail.) for > package which relies on triplet to tell that. At least that triplet > could be canonical and widely accepted for package really caring about > that instead of forcing all package checking compiler options. If a > package needs to support similar thing to mutlilib just like glibc, > that new triplet will simiplifies their decision. > > gcc definitely is not that kind of package as it could be built to > support generate x86-64, x32 and i386 code with the same package and > need a runtime option to tell that. >
I see 3 separate issues: 1. The file name of an x32 binary package needs to be marked as x32. 2. Compilers need a switch to generate x32 code. 3. We need to configure a software package for x32. Which problem are you trying to resolve? Please explain yours if it isn't covered above. -- H.J.
