From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18526 invoked by alias); 26 Mar 2009 12:21:29 -0000 Received: (qmail 17996 invoked by uid 22791); 26 Mar 2009 12:21:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.198.201) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Mar 2009 12:21:19 +0000 Received: from ispserv.ispras.ru (ispserv.ispras.ru [83.149.198.72]) by smtp.ispras.ru (Postfix) with ESMTP id C329D5D4197; Thu, 26 Mar 2009 14:59:30 +0300 (MSK) Received: from [83.149.198.254] ([83.149.198.254]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id n2QCLDkk028593; Thu, 26 Mar 2009 15:21:13 +0300 Message-ID: <49CB7353.2000608@ispras.ru> Date: Thu, 26 Mar 2009 12:21:00 -0000 From: Plotnikov Dmitry User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Yann E. MORIN" CC: crossgcc@sourceware.org Subject: Re: [PATCH] sample config for arm-unkown-linux-gnueabi, gcc-4.4.0, glibc-2.9 References: <49C901C5.4020902@ispras.ru> <200903250003.38849.yann.morin.1998@anciens.enib.fr> In-Reply-To: <200903250003.38849.yann.morin.1998@anciens.enib.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00061.txt.bz2 Hello, Yann! Hello All! > CT_SYSROOT_DIR_PREFIX is *not* an absolute path! > Carefully read the help entry, please! > Sorry, I missed this... > > CT_CC_EXTRA_CONFIG="CFLAGS=-ggdb3" > > > > > Why is that needed? This will build the _cross-gcc_ with debugging symbols, > thus making the cross-gcc bigger and slower! Unless I'm mistaken... > > And unless you are debugging gcc, it is a bad idea, IMHO... We needed debug info in gcc, because there was an error in February snapshot, so crosstool failed at building glibc (it was workarounded then by changing the default optimization level -- there was -O option by default in glibc Makefile with which it failed, but worked with -O2). The issue has been fixed in the current snapshot, and glibc now builds fine with -O. > > # > > # Additional supported languages: > > # > > CT_CC_LANG_CXX=y > > # CT_CC_LANG_FORTRAN is not set > > # CT_CC_LANG_JAVA is not set > > > > > Other gcc versions were able to build the Fortran and Java frontends. > Did you disable them because they did not work, or simply because you > did not need them? We didn't build other languages because we don't need them so we've disabled them just to save time. > So, how did you manage to use the 4.3.3 patchset with 4.4-20090320? We thought we were using this patchset, but actually it isn't applied at all, because we put it on directory 4.4.0 and missed that ct-ng searches it in 4.4-20090320. We believed that the patches were successfully applied since ct-ng said "Applying patches for gcc" in log files and created "gcc*.patched" file. So it seems actually to be working for this target without any patches. --- Dmitry. -- For unsubscribe information see http://sourceware.org/lists.html#faq