From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16499 invoked by alias); 3 Sep 2009 00:20:41 -0000 Received: (qmail 16451 invoked by uid 48); 3 Sep 2009 00:20:26 -0000 Date: Thu, 03 Sep 2009 00:20:00 -0000 Message-ID: <20090903002026.16450.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug bootstrap/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mrs at apple dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00182.txt.bz2 ------- Comment #26 from mrs at apple dot com 2009-09-03 00:20 ------- First, config.guess is orthogonal to the entire discussion, because of that, we never need to mention it again. Next, we do a case analysis of every combination of host/target and buildÂ… We engineer each case to work as desired. Once that is done, you'll discover that we absolutely do need the i386 case to set -m32. If that isn't done, the compiler defaults to 64-bit, and that runs counter to the command implied by the i386, which is to generate 32-bit code. So, the fragment I sent is absolutely required, unchanged. You can know this is true by configure --build=i386-apple-darwin10 on a 64-bit SL box and running file on gcc/expr.o. If it is 64-bit, it is wrong. -m32 should never be set because the x86_64 case. x86_64 means 64-bit, so, the most it implies is -m64. For this reason, #19 must be wrong. x86_64 implying -m64 is useful for gcc's that default to 32-bit code-gen. I don't have that in my tree, as I don't have to worry much about older systems and older compilers. For the FSF tree, it would be nice to have that. You can know this is true by configuring --build=x86_64-apple-darwin on a Leopard box (where gcc defaults to 32-bit) and running file on gcc/expr.o. If it is 32-bit, it is wrong. darwin10 supports and runs on 32-bit only processors. In that case, x86_64 isn't the default code-gen, contrary to your statement in #22. It is improper to test target in #20, as target has no influence. --host=i386-apple-darwin --target=arm-elf implies -m32. Build one, then run file gcc/expr.o. If that file is 64-bit, it is wrong. The changes to configure.ac are independent of config.guess, so your assertion that the changes are only appropriate after config.guess is accepted, is wrong. You can see this by configure --build=i386-apple-darwin10 and running file gcc/expr.o and noticing it is wrong currently on SL. It is says 64-bit, it is wrong. For the comment in #24, no, that isn't its only purpose. The purpose of it would be to allow one to configure --host=i386-apple-darwin10 --build=i386-apple-darwin10, and have gcc do what it is told to do, which is to generate 32-bit binaries. Now, all that aside, you only need to change the patches I suggested, if there is an error in them. You've not identified one error, therefore you don't need to change them. If you want to change them, please explain the error. Lastly, tentative_cc won't work as well as setting CC. My comment in #15 is wrong, CC must be used. As for the libraries. You have to build them appropriately, and give to gcc, the appropriate libs. I build them universal, so what I give gcc is trivially, always good. If you build just one architecture, you have to build the libraries with the same 32/64-bitness as you want to build the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180