From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17021 invoked by alias); 6 Jun 2011 21:41:56 -0000 Received: (qmail 17012 invoked by uid 22791); 6 Jun 2011 21:41:55 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,TW_CX,TW_GC X-Spam-Check-By: sourceware.org Received: from wmh1.mail.saunalahti.fi (HELO wmh1.mail.saunalahti.fi) (62.142.5.133) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Jun 2011 21:41:41 +0000 Received: from [192.168.1.2] (dsl-olubrasgw2-fe72f800-248.dhcp.inet.fi [84.248.114.248]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kai.ruottu@wippies.com) by wmh1.mail.saunalahti.fi (Postfix) with ESMTPSA id 01D0D1FC10B for ; Tue, 7 Jun 2011 00:41:37 +0300 (EEST) Message-ID: <4DED4983.4020608@wippies.com> Date: Tue, 07 Jun 2011 00:03:00 -0000 From: Kai Ruottu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: gcc 4.6.0 References: <000301cc22de$fac4b020$a9d3daad@YOUREDC1953E71> <000c01cc22e5$1559bec0$a9d3daad@YOUREDC1953E71> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg00127.txt.bz2 6.6.2011 23:47, kevin diggs kirjoitti: > Hi, > > On Sat, Jun 4, 2011 at 1:51 PM, Jonathan Wakely wrote: >> >> The docs have said not to do it for at least 10 years so if it worked >> previously you got lucky. >> > > With all the trouble this causes one wonders why it is not caught and > flagged as an error ... Five GCCs, gcc-3.3.6 - 4.2.4 and 4.6.0, made for RHL9 target on CentOS 5.6 and no problems... In a 'build' subdirectory in the main src dir. Before these more than 1000 GCC builds and never any problems... Generally forcing people to make "directory bloat" - separate build dir for each source package - or maybe using some amount of common ones, for instance 5 for max 5 parallel builds for different sources, would sound nuisance for the builders... Building in a separate originally empty build directory inside the source package is much, much clearer... For curiosity I will install RHL9 into an unused P-III 733MHz/512MB PC and see if there really can be some problem with this build platform and the gcc-4.6.0 sources... As $host and $target RHL9 hadn't anything, neither the only-C or C with C++ made any difference... Sad that people cannot do any "> BuildLog 2>&1" redirections or see the right 'config.log's nowadays in order to tell where the smoke was rising... :( The habit to build in an subdirectory of the GCC sources is quite common among the RedHat-derived distros, like CentOS : [root@localhost ~]# gcc -v Reading specs from /usr/lib/gcc/i386-redhat-linux/4.1.2/specs Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-50) and was common already in 2003 in RHL9 : [root@localhost ~]# cd /opt/host-RedHat9.0/usr/bin [root@localhost bin]# ./gcc -v Reading specs from ./../lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) So maybe you guys should start to nag to the Red Hat, CentOS etc. people about their way to build GCCs...