On Tue, Oct 11, 2011 at 9:21 PM, Mike Frysinger <vapier@xxxxxxxxxx> wrote: > On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote: >> On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@xxxxxxxxxx> 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. - michael > -mike > _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
