This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 4.6.0


6.6.2011 23:47, kevin diggs kirjoitti:
Hi,

On Sat, Jun 4, 2011 at 1:51 PM, Jonathan Wakely<jwakely.gcc@gmail.com> 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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]