stable GCC 3.4 configurations

[Andreas Hauser]

dragonflybsd wrote @ Mon, 21 Mar 2005 17:11:58 +0100:

> hmmm - perhaps my problem isn't related to the P4 optimizations at all. 
> I have the same problems, when I don't specify CPUTYPE, but only define 
> CCVER= gcc34 in /etc/make.conf. More curiously, gcc -v still gives
> "gcc version 2.95.4 20020320 [DragonFly]" after make buildworld && make 
> buildkernel (and installing them via make installworld...). So, I've 
> probably done something wrong.
> 
> Are any intermediate steps necessary to switch from gcc 2.9 to gcc 3.4?

No.

> Are my problems related to the "stable tag slip"?

I don't see how.

> btw, without CCVER= gcc34 defined in make.conf, the system builds, 
> installs and works normally with the same source tree.

> # man man
> Formatting page, please wait...Done.
> zcat: input not gziped (MAGIC0)
> zcat: /usr/share/man/cat1/man.1.gz: uncompress failed

> ===> gnu/usr.bin/cc/cc_tools (build-tools)
> /usr/obj/usr/src/btools_i386/usr/src/gnu/usr.bin/cc/cc_tools created for 
> /usr/src/gnu/usr.bin/cc/cc_tools
> gperf -p -j1 -i 1 -g -o -t -G -N is_reserved_word -k1,3,$ 
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c-parse.gperf > 
> c-gperf.h
> Segmentation fault (core dumped)

I see the same.
Chances are this is all due to the stdarg.h change mentioned in another
thread. You might want to try to revert this.
$ cd /usr/src
$ cvs co -D"last month" sys/i386/include/stdarg.h

And before you try again get a clean world (from CD/backup et.c).


Andy