From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: David Edelsohn Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com, autoconf@sourceware.cygnus.com Subject: Re: PA64 configure issues Date: Tue, 25 Apr 2000 12:20:00 -0000 Message-id: <11722.956686264@upchuck> References: <200004251814.OAA28140@mal-ach.watson.ibm.com> X-SW-Source: 2000-04/msg00134.html In message < 200004251814.OAA28140@mal-ach.watson.ibm.com >you write: > Geoff gave the background on 64-bit AIX support which can support > both modes with a single toolchain, defaulting to 32-bit mode. This also > happens to be the way that the AIX product compilers operate, so the two > are consistent. Good. > The above line in your original message jumps out at me. Are you > saying that you must build an entirely separate compiler for PA64? Also, > you did not mention how HP's commercial toolchain operates/defaults. Yes, we have to build a separate toolchain. Among other things PA32 and PA64 use completely different object file formats (SOM & ELF respectively) one supports gnu-ld (PA64) the other will never support gnu-ld (PA32). There's other issues, but those are the two biggest. HP's tools work by having a front-end which invisibly fires up the appropriate 32bit or 64bit tool based on runtime flags. > I would agree that defaulting to 32-bit mode, even on 64-bit > hardware, is the best choice when the hardware can support both modes. OK. > If > the user needs to configure and build a completely separate toolchain for > 64-bit mode, that is much more cumbersome than the AIX toolchain. Yup. And that's the root of the problem I'm trying to resolve. > If HP's > toolchain defaults differently, I think that you need to consider > user-interface compatibility as well. I don't think we're going to have that kind of compatibility. At least not at this stage. jeff