problems using lang/gcc33 or lang/gcc34 for world & kernel & some ports

I know I'm out on a limb when using the newer compilers, but someone's gotta do it and plan for the changes coming with them.  Esp. when I'm overhauling ancient stuff like net/tn3270. ;)

I haven't been able to find any instructional material on how to switch FreeBSD -Current to using the newer compilers for world & kernel.  As you'll see, it wasn't a simple matter of setting CC and other env-vars.  I google'd 'til I gave up, and am writing this report now. ;)

I let the system compiler in 5-Current churn on the two gcc ports.  I believe the logs showed each newer compiler taking over as a bootstrap kind of thing to do the rest of itself.

With the pieces installed under /usr/local, I editted /etc/make.conf to point CC=gcc34, CXX=g++34, and CPP=cpp34.  Part of buildkernel couldn't find them in its PATH (I don't know why, env-vars had 'em), so I then tried setting these with full paths, and that did the trick.

There were other things needed setting, like LIBRARY_PATH and LD_LIBRARY_PATH set to /usr/local/lib/gcc/i386-portbld-freebsd5.2/3.4.0, then I tried to have ldconfig do hints on them during bootup.

Well, to make a long story short, there are too many things in gcc3.4.0+ that will need changes in makefiles to begin with, stuff like certain compiler flags no longer supported, and C++ function defs that fail in the -Current code.  This limb is way too far out, so I'm going to start using gcc3.3.4 now, and redid the make.conf and PATHs and ldconfig etc.

The first problem with gcc3.3.4 was with net/liveMedia -- no matter how I (re)did the -Iinclude parms, such as -I./include, it cannot find the *.hh headers in its own pwd:
--->  Upgrade of net/liveMedia started at: Thu, 01 Apr 2004 20:45:04 -0600
--->  Upgrading 'liveMedia-2004.03.27,1' to 'liveMedia-2004.03.31,1' (net/liveMedia)
--->  Build of net/liveMedia started at: Thu, 01 Apr 2004 20:45:04 -0600
--->  Building '/usr/ports/net/liveMedia'
===>  Vulnerability check disabled
===>  Extracting for liveMedia-2004.03.31,1
>> Checksum OK for live.2004.03.31.tar.gz.
===>  Patching for liveMedia-2004.03.31,1
===>   liveMedia-2004.03.31,1 depends on executable: gmake - found
===>  Configuring for liveMedia-2004.03.31,1
===>  Building for liveMedia-2004.03.31,1
cd liveMedia ; make
/usr/local/bin/g++33  -march=pentium2 -pipe -Os  -march=pentium2 -pipe -Os -march=pentium2 -pipe -Os -c Media.cpp
Media.cpp:21:20: Media.hh: No such file or directory
Media.cpp:22:24: HashTable.hh: No such file or directory
Media.cpp:30: error: syntax error before `*' token
Media.cpp:33: error: `Medium' was not declared in this scope
Media.cpp:33: error: `medium' was not declared in this scope
Media.cpp:33: error: parse error before `*' token
[...]
There were apps that _did_ compile & install during this same run of portupgrade -- the updates for net/openldap22-client went just fine, for example.


I genned world & kernel with the same options in make.conf.  The log is showing several headers not being defined, such as:
/usr/local/bin/gcc33  -march=pentium2 -pipe -Os  -march=pentium2 -pipe -Os -march=pentium2 -I/src/lib/libopie -I/src/lib/libopie/../../contrib/opie -I/src/lib/libopie/../../contrib/opie/libopie  -DKEY_FILE=\"/etc/opiekeys\" -DINSECURE_OVERRIDE -DPATH_ACCESS_FILE=\"/etc/opieaccess\"  -c /src/contrib/opie/libopie/hash.c
/src/contrib/opie/libopie/hash.c: In function `opiehash':
/src/contrib/opie/libopie/hash.c:58: error: `MD5_CTX' undeclared (first use in this function)
/src/contrib/opie/libopie/hash.c:58: error: (Each undeclared identifier is reported only once
/src/contrib/opie/libopie/hash.c:58: error: for each function it appears in.)
/src/contrib/opie/libopie/hash.c:58: error: parse error before "mdx"
/src/contrib/opie/libopie/hash.c:61: error: `mdx' undeclared (first use in this function)
*** Error code 1 (continuing)
[...]
FWIW, all thru the build, this particular problem seemed to confine itself to the missing MD5_CTX def and related matters.  Later on, the installworld would be missing these pieces, so the prior installed code stayed put.

I'm changing -Os to -O2 because there was a known bug with -Os losing symbols, but this was fixed in 3.3.3 final in February 2004.  See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11350>.  Maybe it has resurfaced in our present snapshot of 3.3.4.

OTOH building a kernel with gcc3.3.4 and -Os was quite clean.  I'm running it right now.  But wait 'til you read what I had to fix after installing the new world. ;)
(I picked -Os over -O2 [re: my earlier msgs on these maillists] because this is the default 'deployment' setting in Apple's XCode and may well be part of the boost in speed we've all seen in OSX/Panther: -Os may be the trick of fitting loops inside L1 & L2 hardware caches so they go *ZOOM*. ;)  So if you want a 'free' compiler to generate fast code in 'Free'BSD, then we must get the bugs out of -Os on these li'l endians. ;)

After I installed world built by gcc3.3.4 and -Os, and rebooted, something somewhere had hard-coded '/usr/libexec/ld-elf.so.1'.  Since my /usr is on a separate SCSI2 HD and NO_DYNAMICROOT was *not* in effect, this broke init trying to start /bin/sh /etc/rc.  Fortunately /rescue/sh was there so I could try kludging things back into working.  I'm genning a new world & kernel now with NO_DYNAMICROOT turned *ON*!

I was getting errors due to not finding libgcc_s*, so I also copied the gcc3.3.4 libs to /lib which I left on the root/boot drive (slice... whatever).  Therein is the proof that world will presently be depended on the gcc libs, and you must have them in a known lib location on the root drive.

Getting back to the hard-coded /usr/libexec/ld-elf.so.1: 
To fix the init /bin/sh /etc/rc problem at present, I need ld-elf.so.1 to be under /libexec (which it is) on the boot slice (which it is) and not be ref'd on a mounted slice (/usr/libexec has a symlink to it).  So I editted /src/sys/i386/i386/elf_machdep.c (backing up the original) so that both strings would begin with /libexec.  I don't know how this works; I don't know why changing CC would cause a change here.

That's where I stand now.  Waiting for a NO_DYNAMICROOT system to be genned, along with the hacked elf_machdep.c, which should fix the partial hand-job I must do during booting and /usr not being mounted early enough.

Update:
Okay as I type this, the build has progressed thru the opie part I show above.  Changing -Os to -O2 did not fix the basic problem.

That problem also shows up when building libradius and others:
===> lib/libradius
rm -f .depend
CC='/usr/local/bin/gcc33' mkdep -f .depend -a     /src/lib/libradius/radlib.c
echo libradius.so.1: /usr/obj/src/i386/usr/lib/libmd.a >> .depend
/usr/local/bin/gcc33  -march=pentium2 -pipe -O2  -march=pentium2 -pipe -O2 -march=pentium2 -Wall  -c /src/lib/libradius/radlib.c
/src/lib/libradius/radlib.c: In function `insert_scrambled_password':
/src/lib/libradius/radlib.c:84: error: `MD5_CTX' undeclared (first use in this function)
/src/lib/libradius/radlib.c:84: error: (Each undeclared identifier is reported only once
/src/lib/libradius/radlib.c:84: error: for each function it appears in.)
/src/lib/libradius/radlib.c:84: error: parse error before "ctx"
/src/lib/libradius/radlib.c:98: warning: implicit declaration of function `MD5Init'
/src/lib/libradius/radlib.c:98: error: `ctx' undeclared (first use in this function)
[...]
This only happens in certain libs.  99% of everything else seems to be okay (need to test if -O2 fixes missing symbols ala -Os).

I don't know if we have a bug in the makefiles or if we have a bug in gcc3.3.4. 
I cannot feel 'right' in the GCC forums to discuss it because of the patches being put on it by the FreeBSD port system. <sigh>
There does seem to be a common thread to the missing defs.  But right now I'm too tired to dig deeper. ;)
I'd appreciate any feedback and will read them next week. 
It's gettin' time to have a weekend, and I don't have li'l endians at home. ;)


  --  thx, Paul Seniura
           System Specialist
           State of Okla. D.O.T.