From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12305 invoked by alias); 27 Nov 2004 23:57:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12279 invoked from network); 27 Nov 2004 23:57:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 27 Nov 2004 23:57:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CYCRR-0001e5-4I for ; Sat, 27 Nov 2004 18:57:25 -0500 Date: Sun, 28 Nov 2004 07:58:00 -0000 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Subject: Re: 64-bit configure hell Message-ID: <20041127235725.GA6176@nevyn.them.org> Mail-Followup-To: gcc@gcc.gnu.org References: <41A51487.7070006@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A51487.7070006@apple.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg01071.txt.bz2 On Wed, Nov 24, 2004 at 03:08:55PM -0800, Stan Shebs wrote: > I have a messy configure problem with 64-bit Darwin, and would > like to get some ideas about how to solve. The situation is that > Darwin 8.x aka Tiger is capable of running 64-bit-address-space > programs on G5s, and to support that in GCC I've set up a multilib > for the -m64 option that enables it. This all works on G5 Tiger > now, at least on prime-number days of the month when the moon is > full :-) , and I hope to check in the last bits soon. > > The problem is that Tiger also runs on G4s, which are not capable > of running 64-bit programs - all the machinery is there to build > complete and correct binaries, the kernel just refuses to execute > them. This causes problems for some configure scripts, in particular > those in libstdc++ and libobjc, which want to be able to run > executables. It's not entirely clear to me why that's important, > since the libraries already build and run perfectly fine for > cross-compilers. > > Although it would be good for sales to require that people > building GCC on Darwin upgrade to G5s :-) that's kind of > unfriendly, while producing different results from configure > and make depending on one's CPU is also just asking for > trouble. What other options do I have? Whatever we do to solve this problem, let's try to make it general - there are lots of affected systems. I've seen listed so far: 32-bit AIX s390-ibm-linux-gnu sparc-sun-solaris2.7 I also know of: i386-pc-solaris2.10 And I'd like to be able to enable a 64-bit multilib for: i386-pc-linux-gnu For the last one, Debian hacks it using a change to config-ml.in; we tell the other library builds that they are cross compiling if a trivial 64-bit program can't be run. It works for libstdc++. It doesn't work for libjava due to some bug I never tracked down, and it doesn't work for libgcc (which doesn't have the execute tests problem, but does have the problem Ulrich mentioned of not building if 64-bit libraries are not installed). I think moving libgcc to the top level, followed by cleaning up the tests in config-ml.in, should be enough. Maybe any multilib that can't be linked should be automatically disabled, too? -- Daniel Jacobowitz