This is, for a change, not relative to my Vaio (which still won't boot current, in spite of various improvements apparent in boot -v).
Hardware is a Supermicro P3TDDE (SMP P3-1G, via chipset). 2 60g drives, ad0 has a complete -stable on it, ad1 current. First, GEOM: On trying to do "boot0cfg -s1 /dev/ad0" to get back to booting stable, to try to recover from the next problem, I get "operation not permitted". This didn't happen with NO_GEOM... Is there a new device name to use here? Unfortunately now I can't recover from the next problem without taking a drive (the system in question is remote; fortunately only a few miles). ================== Part 2 ============================= Now for the cross-build problem: ---- On building both stable and current under stable, I get a crippled cpp in current; it can't do *anything* right, and gets various errors in various situations. with source: ------------ gooney# cat hello.c #include <stdio.h> main() { printf("Hello, World!\n"); } ------------------------------ gooney# cc -o hello hello.c hello.c:1: undefined or invalid # directive If I add a comment in the first line, I get: -------------------------------------------- gooney# cc -o hello hello.c hello.c:1: syntax error before `/' and the make world under current dies in the very first mkdep, before the first compile, with another cpp error: -------------------------------------- mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=unix' /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=bsd' /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=FreeBSD' /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A cpu=i386' /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A machine=i386' mkdep: compile failed *** Error code 1 Stop in /usr/src/games/fortune/strfile. *** Error code 1 Stop in /usr/src. *** Error code 1 ----------------------------------- Anyhow, I know from other experience that this is not a fundamental problem with building gcc 3.x under fbsd 4.x; if the gnu build system is used the result works fine. Something is wrong in the 5.x cross-build context that results in a brain-dead cpp. All else "appears" OK, though one wonders. -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message