Re: trouble building XFree86-4-Server under yesterday's current
On Mon, Sep 23, 2002 at 03:13:15PM -0700, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, Sep 23, 2002 at 01:55:18PM +0300, Vallo Kallaste wrote: This isn't a yesterdays problem, I've had this for a month or so. The problem is explicit declaration of -march=p[234], use CPUTYPE=i686 in /etc/make.conf and you get further. The second way is to not set CPUTYPE at all, logic in /usr/share/mk/bsd.cpu.mk will set -mcpu to what appears to fit. That's not true; it adds -mcpu=pentiumpro by default to optimize instruction scheduling for 686-class CPUs (without breaking binary compatibility down to i386s), but it doesnt autodetect anything, and you'll get better performance on a 686-class CPU by specifying it in CPUTYPE (since you'll then also get pentium pro instructions). -mcpu != -march Yes I know and it was what I meant to say. By setting CPUTYPE=p[234] excplicitly in /etc/make.conf you'll get the build failure in XFree86-4-Server because bsd.cpu.mk will set excplicit -march, not -mcpu. But the build error happens _only_ if one sets CPUTYPE=p[234] and not in case CPUTYPE=i686, the latter sets -march=pentiumpro, not -march=pentium[234]. Hope this is all clear now and sorry about confusion, english isn't my native tongue after all. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
`lorder' problem
Anyone experiencing this problem might want to try the following (beware cutpaste). I still don't understand why it is that I don't see it. Is there a hidden build dependency? (I.e., does `sort' need to be added to the list of build-tools?) I'm to tired right now to look at ncurses, but it should be easy to figure out by looking at the manual page for `sort', or by simply aping this example. -GAWollman Index: lorder.sh === RCS file: /home/cvs/src/usr.bin/lorder/lorder.sh,v retrieving revision 1.4 diff -u -r1.4 lorder.sh --- lorder.sh 6 Mar 2001 15:00:32 - 1.4 +++ lorder.sh 24 Sep 2002 06:53:15 - @@ -79,7 +79,7 @@ # sort symbols and references on the first field (the symbol) # join on that field, and print out the file names. -sort +1 $R -o $R -sort +1 $S -o $S +sort -k 2 $R -o $R +sort -k 2 $S -o $S join -j 2 -o 1.1 2.1 $R $S rm -f $R $S To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Mon, Sep 23, 2002 at 03:59:46PM -0400, Alexander Kabaev wrote: On Mon, 23 Sep 2002 12:55:49 -0700 Crist J. Clark [EMAIL PROTECTED] wrote: It seems to have worked. Thanks. Sorry for inconvenience, but could you please check that you got the latest version of the patch. Both versions will fix the bug, but the version I copied on freefall several hours ago appears to be more correct. Not too sure about that. Now I'm getting SIGSEGV again, make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev -I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 Stop in /home/cjc/obj/usr/src.CURRENT/sys/GOKU. *** Error code 1 Stop in /home/cjc/obj/usr/src.CURRENT/sys/GOKU. *** Error code 1 Stop in /usr/src.CURRENT. *** Error code 1 Stop in /usr/src.CURRENT. And I had this patch, $ cvs diff cppmacro.c Index: cppmacro.c === RCS file: /export/freebsd/ncvs/src/contrib/gcc/cppmacro.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 cppmacro.c --- cppmacro.c 1 Sep 2002 20:37:29 - 1.1.1.4 +++ cppmacro.c 23 Sep 2002 20:39:38 - @@ -349,6 +349,8 @@ /* Commit the memory, including NUL, and return the token. */ len = dest - BUFF_FRONT (pfile-u_buff); + if ((size_t) (BUFF_LIMIT (pfile-u_buff) - dest) 1) +_cpp_extend_buff (pfile, pfile-u_buff, 1); BUFF_FRONT (pfile-u_buff) = dest + 1; return new_string_token (pfile, dest - len, len); } For the buildworld and buildkernel. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- === lib/libncurses shift: can't shift that many shift: can't shift that many lib_keyname.c:7: `KEY_A1' undeclared here (not in a function) lib_keyname.c:7: initializer element is not constant lib_keyname.c:7: (near initialization for `_nc_key_names[0].code') lib_keyname.c:7: initializer element is not constant lib_keyname.c:7: (near initialization for `_nc_key_names[0]') lib_keyname.c:8: `KEY_A3' undeclared here (not in a function) lib_keyname.c:8: initializer element is not constant lib_keyname.c:8: (near initialization for `_nc_key_names[1].code') lib_keyname.c:8: initializer element is not constant lib_keyname.c:8: (near initialization for `_nc_key_names[1]') lib_keyname.c:9: `KEY_B2' undeclared here (not in a function) lib_keyname.c:9: initializer element is not constant lib_keyname.c:9: (near initialization for `_nc_key_names[2].code') lib_keyname.c:9: initializer element is not constant lib_keyname.c:9: (near initialization for `_nc_key_names[2]') lib_keyname.c:10: `KEY_BACKSPACE' undeclared here (not in a function) lib_keyname.c:10: initializer element is not constant lib_keyname.c:10: (near initialization for `_nc_key_names[3].code') lib_keyname.c:10: initializer element is not constant lib_keyname.c:10: (near initialization for `_nc_key_names[3]') lib_keyname.c:11: `KEY_BEG' undeclared here (not in a function) lib_keyname.c:11: initializer element is not constant lib_keyname.c:11: (near initialization for `_nc_key_names[4].code') lib_keyname.c:11: initializer element is not constant lib_keyname.c:11: (near initialization for `_nc_key_names[4]') lib_keyname.c:12: initializer element is not constant lib_keyname.c:12: (near initialization for `_nc_key_names[5]') lib_keyname.c:13: `KEY_BTAB' undeclared here (not in a function) lib_keyname.c:13: initializer element is not constant lib_keyname.c:13: (near initialization for `_nc_key_names[6].code') lib_keyname.c:13: initializer element is not constant lib_keyname.c:13: (near initialization for `_nc_key_names[6]') lib_keyname.c:14: `KEY_C1' undeclared here (not in a function) lib_keyname.c:14: initializer element is not constant lib_keyname.c:14: (near initialization for `_nc_key_names[7].code') lib_keyname.c:14: initializer element is not constant lib_keyname.c:14: (near initialization for `_nc_key_names[7]') lib_keyname.c:15: `KEY_C3' undeclared here (not in a function) lib_keyname.c:15: initializer element is not constant lib_keyname.c:15: (near initialization for `_nc_key_names[8].code') lib_keyname.c:15: initializer element is not constant lib_keyname.c:15: (near initialization for `_nc_key_names[8]') lib_keyname.c:16: `KEY_CANCEL' undeclared here (not in a function) lib_keyname.c:16: initializer element is not constant lib_keyname.c:16: (near initialization for `_nc_key_names[9].code') lib_keyname.c:16: initializer element is not constant lib_keyname.c:16: (near initialization for `_nc_key_names[9]') lib_keyname.c:17: `KEY_CATAB' undeclared here (not in a function) lib_keyname.c:17: initializer element is not constant lib_keyname.c:17: (near initialization for `_nc_key_names[10].code') lib_keyname.c:17: initializer element is not constant lib_keyname.c:17: (near initialization for `_nc_key_names[10]') lib_keyname.c:18: `KEY_CLEAR' undeclared here (not in a function) lib_keyname.c:18: initializer element is not constant lib_keyname.c:18: (near initialization for `_nc_key_names[11].code') lib_keyname.c:18: initializer element is not constant lib_keyname.c:18: (near initialization for `_nc_key_names[11]') lib_keyname.c:19: `KEY_CLOSE' undeclared here (not in a function) lib_keyname.c:19: initializer element is not constant lib_keyname.c:19: (near initialization for `_nc_key_names[12].code') lib_keyname.c:19: initializer element is not constant lib_keyname.c:19: (near initialization for `_nc_key_names[12]') lib_keyname.c:20: `KEY_COMMAND' undeclared here (not in a function) lib_keyname.c:20: initializer element is not constant lib_keyname.c:20: (near initialization for `_nc_key_names[13].code') lib_keyname.c:20: initializer element is not constant lib_keyname.c:20: (near initialization for `_nc_key_names[13]')
Re: A different light, perhaps.
Kris Kennaway wrote: ...I expect the problem will be resolved by those who have already said they'll resolve it ;) I obviously missed that discussion. I don't want to pester people about things that they are already working on, so is there somewhere besides the -current and cvs mailing lists I should be watching? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `lorder' problem
On Tue, Sep 24, 2002 at 02:57:09 -0400, Garrett Wollman wrote: Anyone experiencing this problem might want to try the following (beware cutpaste). I still don't understand why it is that I don't see it. Is there a hidden build dependency? (I.e., does `sort' need to be added to the list of build-tools?) Look at the discussion in the current@ maillist about sort breakage with recent new POSIX level define. GNU sort sense POSIX level and remove obsolete syntax to conform it (i.e. +N can be filename). We can either remove new POSIX level define, fix sort not sense ot or fix programs (better). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Mon, Sep 23, 2002 at 12:29:35 +1000, Tim Robbins wrote: A workaround might be to #undef _POSIX2_VERSION after #include'ing unistd.h in posixver.c but I don't think that would be correct. It's probably better Removing compatibility with +pos f.e. they just try to confirm POSIX, because +N can be filename. to either change all the scripts that use the obsolescent +pos -pos syntax to use the new -k syntax or to change _POSIX2_VERSION back to whatever it was before. I think the second is more realistic. I think changing scripts to use -k syntax will be right solution. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `lorder' problem
Garrett Wollman wrote: Anyone experiencing this problem might want to try the following (beware cutpaste). I still don't understand why it is that I don't see it... If you don't see errors while building libc or libncurses just do a 'make clean' in those directories first. I'm too tired right now to look at ncurses... This line in /usr/src/contrib/ncurses/include/MKkey_defs.sh seems to be the fix: sed -e 's/[ ]\+//g' $DATA |sort -n -k 6 $data At least it compiles. Dunno yet if libncurses actually works after compilation ;-) Sleep well! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trouble building XFree86-4-Server under yesterday's current
I have built XFree86 at least 3 times in the past week, all with varying levels of optimization, from -O to -O3 and ALWAYS with -march=pentium3. All of the builds succeeded, although I had stability problems with -O2 and above. Are you _certain_ this is a compiler bug? On Tue, 24 Sep 2002, Vallo Kallaste wrote: On Mon, Sep 23, 2002 at 03:13:15PM -0700, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, Sep 23, 2002 at 01:55:18PM +0300, Vallo Kallaste wrote: This isn't a yesterdays problem, I've had this for a month or so. The problem is explicit declaration of -march=p[234], use CPUTYPE=i686 in /etc/make.conf and you get further. The second way is to not set CPUTYPE at all, logic in /usr/share/mk/bsd.cpu.mk will set -mcpu to what appears to fit. That's not true; it adds -mcpu=pentiumpro by default to optimize instruction scheduling for 686-class CPUs (without breaking binary compatibility down to i386s), but it doesnt autodetect anything, and you'll get better performance on a 686-class CPU by specifying it in CPUTYPE (since you'll then also get pentium pro instructions). -mcpu != -march Yes I know and it was what I meant to say. By setting CPUTYPE=p[234] excplicitly in /etc/make.conf you'll get the build failure in XFree86-4-Server because bsd.cpu.mk will set excplicit -march, not -mcpu. But the build error happens _only_ if one sets CPUTYPE=p[234] and not in case CPUTYPE=i686, the latter sets -march=pentiumpro, not -march=pentium[234]. Hope this is all clear now and sorry about confusion, english isn't my native tongue after all. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
testing point releases
i'm pretty new to current so perhaps this in naive but are there any point releases for testing --- i.e. releases that are known to build properly? the reason i ask is that i've got a problem and am not a coder but essentially have no way to know whether it is worth reporting; whether it is fixed because i can't quickly get the latest buildable and then start to bring specific components up to date and verify. do you really need to be on top of it all to work off of current ? (i.e. i should know where to go back to) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trouble building XFree86-4-Server under yesterday's current
On Tue, Sep 24, 2002 at 09:47:44AM -0400, Wesley Morgan [EMAIL PROTECTED] wrote: I have built XFree86 at least 3 times in the past week, all with varying levels of optimization, from -O to -O3 and ALWAYS with -march=pentium3. All of the builds succeeded, although I had stability problems with -O2 and above. Are you _certain_ this is a compiler bug? To put myself to the safe side, no. I'll do yet another run of compilation on all of the CPUTYPE=p[234] levels and report how it did tomorrow. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trouble building XFree86-4-Server under yesterday's current
On Tue, 24 Sep 2002 17:22:36 +0300 Vallo Kallaste [EMAIL PROTECTED] wrote: On Tue, Sep 24, 2002 at 09:47:44AM -0400, Wesley Morgan [EMAIL PROTECTED] wrote: I have built XFree86 at least 3 times in the past week, all with varying levels of optimization, from -O to -O3 and ALWAYS with -march=pentium3. All of the builds succeeded, although I had stability problems with -O2 and above. Are you _certain_ this is a compiler bug? To put myself to the safe side, no. I'll do yet another run of compilation on all of the CPUTYPE=p[234] levels and report how it did tomorrow. No need. The bug is there and it is triggered by -march={athlon|p[234]}. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- === lib/libncurses shift: can't shift that many shift: can't shift that many lib_keyname.c:7: `KEY_A1' undeclared here (not in a function) lib_keyname.c:7: initializer element is not constant lib_keyname.c:7: (near initialization for `_nc_key_names[0].code') lib_keyname.c:7: initializer element is not constant lib_keyname.c:7: (near initialization for `_nc_key_names[0]') lib_keyname.c:8: `KEY_A3' undeclared here (not in a function) lib_keyname.c:8: initializer element is not constant lib_keyname.c:8: (near initialization for `_nc_key_names[1].code') lib_keyname.c:8: initializer element is not constant lib_keyname.c:8: (near initialization for `_nc_key_names[1]') lib_keyname.c:9: `KEY_B2' undeclared here (not in a function) lib_keyname.c:9: initializer element is not constant lib_keyname.c:9: (near initialization for `_nc_key_names[2].code') lib_keyname.c:9: initializer element is not constant lib_keyname.c:9: (near initialization for `_nc_key_names[2]') lib_keyname.c:10: `KEY_BACKSPACE' undeclared here (not in a function) lib_keyname.c:10: initializer element is not constant lib_keyname.c:10: (near initialization for `_nc_key_names[3].code') lib_keyname.c:10: initializer element is not constant lib_keyname.c:10: (near initialization for `_nc_key_names[3]') lib_keyname.c:11: `KEY_BEG' undeclared here (not in a function) lib_keyname.c:11: initializer element is not constant lib_keyname.c:11: (near initialization for `_nc_key_names[4].code') lib_keyname.c:11: initializer element is not constant lib_keyname.c:11: (near initialization for `_nc_key_names[4]') lib_keyname.c:12: initializer element is not constant lib_keyname.c:12: (near initialization for `_nc_key_names[5]') lib_keyname.c:13: `KEY_BTAB' undeclared here (not in a function) lib_keyname.c:13: initializer element is not constant lib_keyname.c:13: (near initialization for `_nc_key_names[6].code') lib_keyname.c:13: initializer element is not constant lib_keyname.c:13: (near initialization for `_nc_key_names[6]') lib_keyname.c:14: `KEY_C1' undeclared here (not in a function) lib_keyname.c:14: initializer element is not constant lib_keyname.c:14: (near initialization for `_nc_key_names[7].code') lib_keyname.c:14: initializer element is not constant lib_keyname.c:14: (near initialization for `_nc_key_names[7]') lib_keyname.c:15: `KEY_C3' undeclared here (not in a function) lib_keyname.c:15: initializer element is not constant lib_keyname.c:15: (near initialization for `_nc_key_names[8].code') lib_keyname.c:15: initializer element is not constant lib_keyname.c:15: (near initialization for `_nc_key_names[8]') lib_keyname.c:16: `KEY_CANCEL' undeclared here (not in a function) lib_keyname.c:16: initializer element is not constant lib_keyname.c:16: (near initialization for `_nc_key_names[9].code') lib_keyname.c:16: initializer element is not constant lib_keyname.c:16: (near initialization for `_nc_key_names[9]') lib_keyname.c:17: `KEY_CATAB' undeclared here (not in a function) lib_keyname.c:17: initializer element is not constant lib_keyname.c:17: (near initialization for `_nc_key_names[10].code') lib_keyname.c:17: initializer element is not constant lib_keyname.c:17: (near initialization for `_nc_key_names[10]') lib_keyname.c:18: `KEY_CLEAR' undeclared here (not in a function) lib_keyname.c:18: initializer element is not constant lib_keyname.c:18: (near initialization for `_nc_key_names[11].code') lib_keyname.c:18: initializer element is not constant lib_keyname.c:18: (near initialization for `_nc_key_names[11]') lib_keyname.c:19: `KEY_CLOSE' undeclared here (not in a function) lib_keyname.c:19: initializer element is not constant lib_keyname.c:19: (near initialization for `_nc_key_names[12].code') lib_keyname.c:19: initializer element is not constant lib_keyname.c:19: (near initialization for `_nc_key_names[12]') lib_keyname.c:20: `KEY_COMMAND' undeclared here (not in a function) lib_keyname.c:20: initializer element is not constant lib_keyname.c:20: (near initialization for `_nc_key_names[13].code') lib_keyname.c:20: initializer element is not constant lib_keyname.c:20: (near initialization for
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002 10:52:10 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: Do you want me to try your first patch? I never got a chance to test it.(And no longer have a copy of it, either.) No, there is a bug in the patch you tested. Could you please try again with an updated patch? URL is the same http://people.freebsd.org/~kan/gcc-cpp.diff -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Tue, 24 Sep 2002 00:00:45 -0700 Crist J. Clark [EMAIL PROTECTED] wrote: Not too sure about that. Now I'm getting SIGSEGV again, You are right. There was a stupid mistake in the latest version, sorry. Could you try yet another patch? http://people.freebsd.org/~kan/gcc-cpp.diff -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Alexander Kabaev wrote: On Tue, 24 Sep 2002 10:52:10 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: Do you want me to try your first patch? I never got a chance to test it.(And no longer have a copy of it, either.) No, there is a bug in the patch you tested. Could you please try again with an updated patch? URL is the same http://people.freebsd.org/~kan/gcc-cpp.diff -- Alexander Kabaev That doesn't seem to have fixed the problem, and the backtrace looks to be the same: #0 0x08058cb6 in cpp_ideq () #1 0x080592e6 in _cpp_lex_direct () #2 0x08058f6d in _cpp_lex_token () #3 0x08056465 in cpp_macro_definition () #4 0x080564ed in cpp_macro_definition () #5 0x0805672b in _cpp_handle_directive () #6 0x08058f9c in _cpp_lex_token () #7 0x08055832 in cpp_get_token () #8 0x0805595d in cpp_scan_nooutput () #9 0x08048409 in do_preprocessing () #10 0x08048241 in main () #11 0x08048145 in _start () Thanks to the wonderful sort breakage, I'm seeing this if I touch cppmacro.c and make again: === cc_int cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -c /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cppmacro.c -o cppmacro.o building static cc_int library sort: open failed: +1: No such file or directory sort: open failed: +1: No such file or directory ranlib libcc_int.a Any chance that's causing a problem? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Sun, 22 Sep 2002, Alexander Kabaev wrote: On Sun, 22 Sep 2002 18:51:14 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: I'm seeing the segfault in the kernel make depend step, just as someone else reported. OK, could you please try the patch at http://people.freebsd.org/~kan/gcc-cpp.diff and let me know the results. -- Alexander Kabaev This version of the gcc-cpp.diff patch: Index: cppmacro.c === RCS file: /usr/ncvs/src/contrib/gcc/cppmacro.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 cppmacro.c --- cppmacro.c 1 Sep 2002 20:37:29 - 1.1.1.4 +++ cppmacro.c 23 Sep 2002 17:44:32 - @@ -349,6 +349,8 @@ /* Commit the memory, including NUL, and return the token. */ len = dest - BUFF_FRONT (pfile-u_buff); + if ((size_t) (BUFF_LIMIT (pfile-u_buff) - dest) 1) +_cpp_extend_buff (pfile, pfile-u_buff, 1); BUFF_FRONT (pfile-u_buff) = dest + 1; return new_string_token (pfile, dest - len, len); } Does _not_ fix the problem for me. Here's the backtrace of the crash with the patch applied: #0 0x08058cb6 in cpp_ideq () #1 0x080592e6 in _cpp_lex_direct () #2 0x08058f6d in _cpp_lex_token () #3 0x08056465 in cpp_macro_definition () #4 0x080564ed in cpp_macro_definition () #5 0x0805672b in _cpp_handle_directive () #6 0x08058f9c in _cpp_lex_token () #7 0x08055832 in cpp_get_token () #8 0x0805595d in cpp_scan_nooutput () #9 0x08048409 in do_preprocessing () #10 0x08048241 in main () #11 0x08048145 in _start () And of course, it's this part of a buildkernel where it happens: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. Do you want me to try your first patch? I never got a chance to test it. (And no longer have a copy of it, either.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
Thanks to the wonderful sort breakage, I'm seeing this if I touch cppmacro.c and make again: === cc_int cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\-I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -c/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cppmacro.c -o cppmacro.o building static cc_int library sort: open failed: +1: No such file or directory sort: open failed: +1: No such file or directory ranlib libcc_int.a Any chance that's causing a problem? It is certainly a possibility. Were all the binaries dependent on the cc_int relinked? Was cc_int itself updated with a newer cppmacro.o file? You might want to do a make clean in /usr/src/gnu/usr.bin/cc before building a new copy of gcc. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
smbus, geom or ufs attr break the kernel
Hi! Something checked-in yesterday broke the kernel badly.. Some of these options or a combination of these break the kernel badly. If they're activatet then not all devices are created by devfs (ttv* is missing..). Even without devfs ttv* isn't working... Commenting this out of my config fixed the prob for me. options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL options GEOM device smbus# Bus support, required for smb below. device viapm device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge Marc msg43315/pgp0.pgp Description: PGP signature
Re: `lorder' problem
In message [EMAIL PROTECTED], Garrett Wollman writes: Anyone experiencing this problem might want to try the following (beware cutpaste). I still don't understand why it is that I don't see it. Is there a hidden build dependency? (I.e., does `sort' need to be added to the list of build-tools?) It's because sort is not in build-tools and you havn't done an installworld. cd /usr/src/usr.bin/sort make obj make depend make all install should make you see it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbus, geom or ufs attr break the kernel
In message [EMAIL PROTECTED], Marc Recht writes: --=.t8Cw0UW_4O(CPO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! Something checked-in yesterday broke the kernel badly.. Some of these options or a combination of these break the kernel badly. If they're activatet then not all devices are created by devfs (ttv* is missing..). Even without devfs ttv* isn't working... Commenting this out of my config fixed the prob for me. options UFS_ACL This is a major suspect. Have you read what it does ? options GEOM This I can almost guarantee you, is not the culprit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Coredump from pkg_add + analysis
pkg_add coredumps when installing dependencies from remote. This is really annoying because you have to manually track down dependencies and install them (say, for a critical package like cvsup). This has been reported multiple times and is 100% repeatable. It's been broken for a few months (ever since *conn was added to libfetch). Anyway, here's the trace and analysis. (gdb) bt #0 0x2809d6fe in SSL_write () from /usr/lib/libssl.so.2 #1 0x080564f0 in _fetch_write (conn=0x80940c0, buf=0x8098200 NOOP, len=4) at /usr/src/lib/libfetch/common.c:485 #2 0x080565a7 in _fetch_putln (conn=0x80940c0, str=0x8098200 NOOP, len=134840832) at /usr/src/lib/libfetch/common.c:513 #3 0x08054023 in _ftp_cmd (conn=0x80940c0, fmt=0x8098200 NOOP) at /usr/src/lib/libfetch/ftp.c:187 #4 0x08055524 in _ftp_cached_connect (url=0x80940c0, purl=0x8098200, flags=0x8098200 NOOP) at /usr/src/lib/libfetch/ftp.c:867 #5 0x0805577c in _ftp_request (url=0x8093000, op=0x8059f29 RETR, us=0x0, purl=0x0, flags=0x0) at /usr/src/lib/libfetch/ftp.c:933 #6 0x080558e0 in fetchXGetFTP (url=0x2f363833, us=0x2f363833, flags=0x8098200 NOOP) at /usr/src/lib/libfetch/ftp.c:967 #7 0x08050e76 in fetchXGet (URL=0x8093000, us=0x0, flags=0x0) at /usr/src/lib/libfetch/fetch.c:83 #8 0x080511c8 in fetchXGetURL (URL=0x8098200 NOOP, us=0x8098200, flags=0x8098200 NOOP) at /usr/src/lib/libfetch/fetch.c:180 #9 0x08051200 in fetchGetURL (URL=0x8098200 NOOP, flags=0x8098200 NOOP) at /usr/src/lib/libfetch/fetch.c:192 #10 0x080500c1 in fileGetURL () #11 0x0804b53d in pkg_do ( pkg=0x805e880 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All/xpdf-1.01.tbz;) at /usr/src/usr.sbin/pkg_install/add/perform.c:297 #12 0x0804aceb in pkg_perform (pkgs=0x8090c80) at /usr/src/usr.sbin/pkg_install/add/perform.c:50 #13 0x0804aa4f in real_main (argc=-1077937142, argv=0xbfbffb0c) at /usr/src/usr.sbin/pkg_install/add/main.c:215 #14 0x0804d41e in main (argc=134840832, argv=0xbfbffb00) at /usr/src/usr.sbin/pkg_install/lib/pkgwrap.c:88 #15 0x0804a5c9 in _start () (gdb) fr 1 #1 0x080564f0 in _fetch_write (conn=0x80940c0, buf=0x8098200 NOOP, len=4) at /usr/src/lib/libfetch/common.c:485 485 wlen = SSL_write(conn-ssl, buf, len); (gdb) list 480 } 481 } 482 errno = 0; 483 #ifdef WITH_SSL 484 if (conn-ssl != NULL) 485 wlen = SSL_write(conn-ssl, buf, len); 486 else 487 #endif 488 wlen = write(conn-sd, buf, len); 489 if (wlen == 0) (gdb) print conn $1 = (struct fetchconn *) 0x80940c0 (gdb) print *conn $2 = {sd = 1651863599, buf = 0x6572462f Address 0x6572462f out of bounds, bufsize = 1146307173, buflen = 1919905839, err = 1764717428, ssl = 0x2f363833, ssl_ctx = 0x6b636170, ssl_cert = 0x73656761, ssl_meth = 0x632d352d, ref = 1701999221} (gdb) print conn-ssl $3 = (struct ssl_st *) 0x2f363833 Obviously, the problem is that we're bogusly sending an FTP command to SSL because conn (and conn-ssl) was overwritten with garbage. Looking into it further, the problem appears to be with cached_connection in ftp.c. Often, the connection is closed (when the reference count goes to 0) but cached_connection is never set to NULL thus causing it to be reused even though *conn is invalid. There's a bit of a layering problem with the ftp/fetch semantics. _fetch_close() is used to shutdown the connection (and handles reference counting but the connection caching is done at the ftp layer. Either the connection cache should be moved to the fetch layer so open/close can deal with it properly (better) or the ftp layer needs to check for a ref count of 1 and invalidate the cache before closing it (worse). A lot of people would really really appreciate it if someone would choose an approach and fix this. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbus, geom or ufs attr break the kernel
That's an odd set of things to have break in concert. The UFS options should not affect devfs at all. That said, your best bet is probably to turn off sets of related options until you figure out what the source is. Obvious candidates would be to turn off the UFS options as a set, GEOM, and then the smbus support, and see what makes things work again. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Tue, 24 Sep 2002, Marc Recht wrote: Hi! Something checked-in yesterday broke the kernel badly.. Some of these options or a combination of these break the kernel badly. If they're activatet then not all devices are created by devfs (ttv* is missing..). Even without devfs ttv* isn't working... Commenting this out of my config fixed the prob for me. options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL options GEOM device smbus# Bus support, required for smb below. device viapm device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
Mike Silbersack wrote: Thanks to the wonderful sort breakage, I'm seeing this if I touch cppmacro.c and make again: building static cc_int library sort: open failed: +1: No such file or directory sort: open failed: +1: No such file or directory This is easily fixed by patching /usr/bin/lorder to use the newer syntax for 'sort'. See Garrett's patch in the thread entitled 'lorder problem'. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbus, geom or ufs attr break the kernel
options UFS_ACL This is a major suspect. Have you read what it does ? Of course. It has been working for weeks.. options GEOM This I can almost guarantee you, is not the culprit. You're right. The smbus/ic/iic/iicsmb stuff is what breaks the kernel for me. Marc msg43321/pgp0.pgp Description: PGP signature
Re: smbus, geom or ufs attr break the kernel
That's an odd set of things to have break in concert. The UFS options should not affect devfs at all. That said, your best bet is probably to turn off sets of related options until you figure out what the source is. Obvious candidates would be to turn off the UFS options as a set, GEOM, and then the smbus support, and see what makes things work again. I did and it's the smbus/ic/iic/iicsmb stuff what breaks the kernel for me. Maybe it was the commit by Nicolas Souchu (smbus.c 1.16). Marc msg43322/pgp0.pgp Description: PGP signature
Re: `lorder' problem
On Tue, Sep 24, 2002 at 05:46:15 -0700, walt wrote: This line in /usr/src/contrib/ncurses/include/MKkey_defs.sh seems to be the fix: sed -e 's/[ ]\+//g' $DATA |sort -n -k 6 $data I forward your fix to ncurses author. Please send your fix to our ncurses maintainer ([EMAIL PROTECTED]) too for commiting. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbus, geom or ufs attr break the kernel
On Tue, 24 Sep 2002, Marc Recht wrote: That's an odd set of things to have break in concert. The UFS options should not affect devfs at all. That said, your best bet is probably to turn off sets of related options until you figure out what the source is. Obvious candidates would be to turn off the UFS options as a set, GEOM, and then the smbus support, and see what makes things work again. I did and it's the smbus/ic/iic/iicsmb stuff what breaks the kernel for me. Maybe it was the commit by Nicolas Souchu (smbus.c 1.16). Yeah, you probably didn't want a console anyway. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, David Wolfskill wrote: building static cc_int library sort: open failed: +1: No such file or directory sort: open failed: +1: No such file or directory ranlib libcc_int.a Any chance that's causing a problem? To fix that (regardless of sort), s/sort +1/sort -k 2/ in `which lorder` (and /usr/src/usr.bin/lorder/lorder.sh). Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill[EMAIL PROTECTED] Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. Or better yet, I'm just including my kernel config. Presumably with it you'll be able to recreate the problem on your system. If not, then we can see what else differs about my system. Mike Silby Silbersack # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.308 2001/05/13 20:52:39 phk Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident PATROCLES maxusers0 #options RANDOM_IP_ID options UFS_DIRHASH options DIAGNOSTIC #makeoptions NO_WERROR=true device smbus # Bus support, required for smb below. device intpm device alpm device ichsmb device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge #device pcf #To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options DDB #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options MD_ROOT #MD is a potential root device #optionsNFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options PSEUDOFS options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current #optionsDDB #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsWITNESS # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices
Re: -mcpu=pentiumpro still evil?
On Tue, Sep 24, 2002 at 02:05:08PM -0500, Mike Silbersack wrote: Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. Does this work for you: cd /usr/src/gnu/usr.bin/cc make DEBUG_FLAGS=-g install -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `lorder' problem
You may already know this, but the GNU sort also check for the environment variable _POSIX2_VERSION, and according to the docs setting it to 199209 will revert to the old style usage (and unbreak world I am guessing) On Tue, 24 Sep 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Garrett Wollman writes: Anyone experiencing this problem might want to try the following (beware cutpaste). I still don't understand why it is that I don't see it. Is there a hidden build dependency? (I.e., does `sort' need to be added to the list of build-tools?) It's because sort is not in build-tools and you havn't done an installworld. cd /usr/src/usr.bin/sort make obj make depend make all install should make you see it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: testing point releases
On Tue, Sep 24, 2002 at 02:24:38PM +0100, Fergus Cameron wrote: i'm pretty new to current so perhaps this in naive but are there any point releases for testing --- i.e. releases that are known to build properly? The Developer Preview #2 should be out sometime in the next month or two. Aside from that you can just watch mailing list traffic and wait for periods of quiet (and then update to the source tree from a few days previously) do you really need to be on top of it all to work off of current ? (i.e. i should know where to go back to) Well, you do need to have some kind of exit strategy if things go wrong. That can be as crude as 'reinstall the system from your 4.6-R disks', but if you want to struggle through the periodic problems you'll need some technical knowledge. Kris msg43328/pgp0.pgp Description: PGP signature
Partial list of scripts broken by 'sort'
Just a quick scan turns up these suspects in need of revision: /usr/src/etc/security /usr/src/etc/periodic/daily/440.status-named /usr/src/etc/periodic/monthly/200.accounting /usr/src/etc/periodic/security/100.chksetuid /usr/src/etc/periodic/security/800.loginfail /usr/src/etc/periodic/security/900.tcpwrap /usr/src/contrib/ncurses/include/MKkey_defs.sh /usr/src/binutils/ltmain.sh /usr/ports/Makefile /usr/src/crypto/heimdal/ltmain.sh /usr/share/doc/usd/13.viref/Makefile /usr/src/tools/diag/httpd-error/httpd-error /usr/src/usr.bin/lorder/lorder.sh /usr/src/usr.bin/vgrind/vgrind.sh /usr/src/usr.sbin/quot/quot.8 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `lorder' problem
On Tue, Sep 24, 2002 at 22:32:01 +0400, Andrey A. Chernov wrote: Please send your fix to our ncurses maintainer ([EMAIL PROTECTED]) too for commiting. Not needed, I use _POSIX_VERSION=199209 environment workaround in lib/libncurses/Makefile. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Tim Robbins wrote: On Sun, Sep 22, 2002 at 01:43:38PM -0700, Steve Kargl wrote: On Sun, Sep 22, 2002 at 10:17:41PM +0200, Poul-Henning Kamp wrote: flat# date | sort +5n sort: open failed: +5n: No such file or directory This breaks the build in libncurses... POSIX via wollman. See revision 1.58 of /usr/include/unistd.h, i.e., /* Define the versions we target for compliance. */ #define _POSIX_VERSION 200112L #define _POSIX2_VERSION 200112L See email in the last 24 hours from walt about problems building libc and Tim Robbins response to the problem. I didn't read src/contrib/gnu-sort/lib/posixver.c carefully enough to notice that it uses the the _POSIX2_VERSION macro, I thought it only used the environment variable by that same name. A workaround might be to #undef _POSIX2_VERSION after #include'ing unistd.h in posixver.c but I don't think that would be correct. It's probably better to either change all the scripts that use the obsolescent +pos -pos syntax to use the new -k syntax or to change _POSIX2_VERSION back to whatever it was before. I think the second is more realistic. Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. I am most unhappy with this change. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Here's my suggested fix: stash% pwd /usr/src/gnu/usr.bin/sort stash% cvs diff -uN cvs diff: Diffing . Index: posixver.c === RCS file: posixver.c diff -N posixver.c --- /dev/null 1 Jan 1970 00:00:00 - +++ posixver.c 24 Sep 2002 20:37:22 - @@ -0,0 +1,8 @@ +/* + * Tell GNU sort(1) to implement the obsolete +1 -0 syntax even though + * it has been removed from the version of POSIX that the rest of + * the system conforms to. + */ +int posix2_version(void) { + return 0; +} If it's too confusing to have files with the same names in /usr/src/gnu/usr.bin/sort and /usr/src/contrib/gnu-sort/lib this one could be renamed (e.g. to posixver-notreally.c) with a corresponding Makefile change. I am in the middle of a buildworld with this change. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Strange crash dump data.
I left my FreeBSD-current workstation at home running for a few hours, and returned to find the configured snake saver running. When I pressed Shift to get the screen saver to stop, the console went blank and stopped updating. I broke into DDB and used panic to stop everything (mostly a couple of compiles in /usr/ports running). The resulting crash dump seems strange though :-/ Looking at the code, I'd expect atkbd_isa_intr() to be called with a non-NULL pointer as its only argument. The debugger shows that this isn't the case though. Look for the lines that start with for comments that I've added to the script log. %%% Script started on Tue Sep 24 21:02:44 2002 root@hades[21:03]/var/crash# gdb -k /usr/obj/usr/src/sys/HADES5/kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bwrite: buffer is not busy??? panic messages: --- panic: from debugger syncing disks... panic: bwrite: buffer is not busy??? Uptime: 33m43s Dumping 64 MB ata0: resetting devices .. done 16 32 48 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223 223 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223 #1 0xc01d2b1c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355 #2 0xc01d2cf0 in poweroff_wait (junk=0xc033086b, howto=-1038164136) at /usr/src/sys/kern/kern_shutdown.c:508 #3 0xc020aedd in bwrite (bp=0x104) at /usr/src/sys/kern/vfs_bio.c:798 #4 0xc020c245 in vfs_bio_awrite (bp=0xc21edeb0) at /usr/src/sys/kern/vfs_bio.c:1639 #5 0xc01a89d8 in spec_fsync (ap=0xc5b1aa10) at /usr/src/sys/fs/specfs/spec_vnops.c:406 #6 0xc01a85b7 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:124 #7 0xc02b38a8 in ffs_sync (mp=0xc0f32800, waitfor=2, cred=0xc06ade80, td=0xc037d580) at vnode_if.h:615 #8 0xc021b3f4 in sync (td=0xc037d580, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:130 #9 0xc01d2759 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:264 #10 0xc01d2cf0 in poweroff_wait (junk=0xc031a5a8, howto=-978211964) at /usr/src/sys/kern/kern_shutdown.c:508 #11 0xc0140b61 in db_panic () at /usr/src/sys/ddb/db_command.c:449 #12 0xc0140b00 in db_command (last_cmdp=0xc035d760, cmd_table=0xc031a5a8, aux_cmd_tablep=0xc06bc180, aux_cmd_tablep_end=0x100) at /usr/src/sys/ddb/db_command.c:345 #13 0xc0140bcf in db_command_loop () at /usr/src/sys/ddb/db_command.c:471 #14 0xc01430be in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72 #15 0xc02ecf92 in kdb_trap (type=3, code=0, regs=0xc5b1ac20) at /usr/src/sys/i386/i386/db_interface.c:166 #16 0xc02fbb88 in trap (frame= {tf_fs = -1069678568, tf_es = -978255856, tf_ds = 16, tf_edi = -1069627712, tf_esi = -1069708480, tf_ebp = -978211740, tf_isp = -978211764, tf_ebx = 0, tf_edx = 0, tf_ecx = -1069781504, tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1070673419, tf_cs = -1070333944, tf_eflags = 662, tf_esp = 0, tf_ss = -978211668}) at /usr/src/sys/i386/i386/trap.c:605 #17 0xc02ee3a8 in calltrap () at /var/tmp/ccn56iVL.s:98 #18 0xc02e9dac in scgetc (sc=0xc03ec6c0, flags=2) at /usr/src/sys/dev/syscons/syscons.c:3301 #19 0xc02e6148 in sckbdevent (thiskbd=0xc03c7180, event=0, arg=0xc03ec6c0) at /usr/src/sys/dev/syscons/syscons.c:622 #20 0xc02d9b14 in atkbd_intr (kbd=0xc03c7180, arg=0x0) at /usr/src/sys/dev/kbd/atkbd.c:458 #21 0xc03048aa in atkbd_isa_intr (arg=0x0) at /usr/src/sys/isa/atkbd_isa.c:175 #22 0xc01c2560 in ithread_loop (arg=0xc06b0900) at /usr/src/sys/kern/kern_intr.c:534 #23 0xc01c17a9 in fork_exit (callout=0xc01c23ec ithread_loop, arg=0xc06b0900, frame=0xc5b1ad48) at /usr/src/sys/kern/kern_fork.c:848 (kgdb) up 23 #23 0xc01c17a9 in fork_exit (callout=0xc01c23ec ithread_loop, arg=0xc06b0900, frame=0xc5b1ad48) at /usr/src/sys/kern/kern_fork.c:848 848 callout(arg, frame); (kgdb) down 1 #22 0xc01c2560 in ithread_loop (arg=0xc06b0900) at /usr/src/sys/kern/kern_intr.c:534 534 ih-ih_handler(ih-ih_argument); (kgdb) p *ih $1 = {ih_handler = 0xc0304894 atkbd_isa_intr, ih_argument = 0xc03c7180, ih_flags = 0, ih_name = 0xc067d7f0 atkbd0, ih_ithread = 0xc06b0900, ih_need = 0, ih_next = {tqe_next = 0x0, tqe_prev = 0xc06b0950}, ih_pri = 24 '\030'} (kgdb) down 1 #21 0xc03048aa in atkbd_isa_intr (arg=0x0) at /usr/src/sys/isa/atkbd_isa.c:175 175 (*kbdsw[kbd-kb_index]-intr)(kbd, NULL); Shouldn't arg be equal to 0xc03c7180 here? I mean, the same as ih-ih_argument in the previous stack frame? (kgdb) list 170 atkbd_isa_intr(void *arg) 171 { 172 keyboard_t *kbd; 173 174 kbd = (keyboard_t *)arg; 175
Re: Who broke sort(1) ?
On Tue, Sep 24, 2002 at 13:30:11 -0700, Peter Wemm wrote: Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. I am most unhappy with this change. :-( It will be possible to have both variants, but +N is valid filename per POSIX, so obsoleted syntax can't be supported. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Peter Wemm wrote: Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. I am most unhappy with this change. :-( I'll say it again: unconditionally complying POSIX is an impediment to getting real work done. 8-(. I would be very happy if a lot of the POSIX semantics could go live in a user space library somewhere, and leave programmers alone. Signals semantics and file locking alone are enough to justify that. Yeah, it's nice to have a Big Red Switch(tm) that would turn off all behaviour not mandated by some standard, so that you could flip the siwtch, and *know* that the programs you write will run anywhere the standard is implemented. It's a good goal for a platform, to let it act as a unified porting environment. The key thing here, though, is that it needs to be *a* swtich, and it needs to be a *switch*. For the particular case of sort, it would be nice if it did what it was supposed to do, and got anal about POSIX _only_ if there was an environment variable set. Maybe there would be bonus points if the system itself could be built with the switch flipped, but that's something that can be done incrementally, later, by People Who Care(tm). Until sh, make, tar, and so on also drop behaviours that are not specified by POSIX, it's really silly to make sort drop them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Laptop and ACPI
I keep getting my dmesg flooded with this: ACPI-1046: *** Error: AcpiEvGpeDispatch: No handler or method for GPE[9], disabling event ACPI-1046: *** Error: AcpiEvGpeDispatch: No handler or method for GPE[9], disabling event And it feels kind of warm, is there a way to force the fans on? I thought a saw an example in the list a while back, but deleted it from my mta, and i searched the archive but i could only find the first message in the string. Justin Bastedo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Tue, Sep 24, 2002 at 13:43:08 -0700, Bill Fenner wrote: Here's my suggested fix: Please, no. They do the right thing. You can bypass it setting _POSIX2_VERSION=199209 in the environment. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Tue, Sep 24, 2002 at 11:43:22AM -0400, Alexander Kabaev wrote: On Tue, 24 Sep 2002 00:00:45 -0700 Crist J. Clark [EMAIL PROTECTED] wrote: Not too sure about that. Now I'm getting SIGSEGV again, You are right. There was a stupid mistake in the latest version, sorry. Could you try yet another patch? http://people.freebsd.org/~kan/gcc-cpp.diff Nope, still getting it. As for your other question about the configuration, it looks like it's, options IPSEC_ESP That is killing it. If I comment out that option, I get past that initial mkdep. The whole configuration is attached. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] # # $Id: GOKU,v 1.7 2002/07/30 07:50:02 cjc Exp cjc $ # machine i386 cpu I686_CPU ident GOKU maxusers0 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options FFS #Berkeley Fast Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING options SOFTUPDATES device isa device pci options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPV6FIREWALL#firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPDIVERT#divert sockets #optionsIPFILTER#ipfilter support #optionsIPFILTER_LOG#ipfilter logging #optionsIPFILTER_DEFAULT_BLOCK #block all packets by default device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # Floating point support - do not disable. device npx # Power management support #device apm # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # PCI Ethernet NICs. device miibus device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices - the number indicates how many units to allocated. device random # Entropy device device loop# Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # ttys (telnet etc) device md # Memory disks device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf #Berkeley packet filter # Give sound a shot device pcm # USB device device usb
Re: Who broke sort(1) ?
Please, no. They do the right thing. I guess there are varying definitions of what the right thing is. I don't think it's widely known that the +/- syntax was obsoleted. I am vaguely a standards weenie and I didn't know. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Tue, 24 Sep 2002 13:30:11 -0700, Peter Wemm [EMAIL PROTECTED] said: Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. I am most unhappy with this change. :-( The time to complain about it was back in 1992when the old syntax was labeled ``deprecated'' by P1003.2, or in 1999 when the revision cycle was just heating up. Old deprecated features were automatically dropped leading up to the 2001 revision, unless someone could make a case for their retention. That case wasn't made in the case of `sort', and as a result the Standard no longer permits the old syntax. It's not like people didn't have nine years' advance warning to fix their scripts. FreeBSD supported `-k' in 1.0; see http://www.freebsd.org/cgi/cvsweb.cgi/src/gnu/usr.bin/sort/Attic/sort.c?rev=1.1content-type=text/x-cvsweb-markup. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Craig Rodrigues wrote: On Tue, Sep 24, 2002 at 02:05:08PM -0500, Mike Silbersack wrote: Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. Does this work for you: cd /usr/src/gnu/usr.bin/cc make DEBUG_FLAGS=-g install -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] Nope, that doesn't build in debugging symbols either. Neither does adding +g or +gstabs+ to CFLAGS in make.conf. Hmph. Maybe I need to add LDFLAGS or something, I'm not sure. (I'm really bad with Makefiles.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Until sh, make, tar, and so on also drop behaviours that are not specified by POSIX, it's really silly to make sort drop them. It's not that the +x/-y argument syntax is not specified - it's that it's specifically disallowed. (I disagree with that restriction, but let's at least have the right argument.) Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Tue, Sep 24, 2002 at 13:59:02 -0700, Bill Fenner wrote: Please, no. They do the right thing. I guess there are varying definitions of what the right thing is. I mean just: 1) We all agree targeting POSIX, so POSIX conformance is the right thing. 2) If we use _POSIX2_VERSION 2001* in our headers, we target this POSIX level where +N is clearly dropped (and was as 'depricated' long time). I don't think it's widely known that the +/- syntax was obsoleted. It was known about 10 years, but not widely. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
It's not like people didn't have nine years' advance warning to fix their scripts. When's the first time the FreeBSD sort(1) man page mentioned that this syntax was deprecated? Can we at least start from there? Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002 16:07:39 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: On Tue, 24 Sep 2002, Craig Rodrigues wrote: On Tue, Sep 24, 2002 at 02:05:08PM -0500, Mike Silbersack wrote: Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. cd /usr/src/gnu/usr.bin/cc CFLAGS=-g STRIP= make clean all install Always worked for me. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Garrett Wollman wrote: On Tue, 24 Sep 2002 13:30:11 -0700, Peter Wemm [EMAIL PROTECTED] said: Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. I am most unhappy with this change. :-( The time to complain about it was back in 1992when the old syntax was labeled ``deprecated'' by P1003.2, or in 1999 when the revision cycle was just heating up. Old deprecated features were automatically dropped leading up to the 2001 revision, unless someone could make a case for their retention. That case wasn't made in the case of `sort', and as a result the Standard no longer permits the old syntax. It's not like people didn't have nine years' advance warning to fix their scripts. Closed payware standards do not count as 'fair warning'. I still have never been able to see a posix standard. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Andrey A. Chernov wrote: On Tue, Sep 24, 2002 at 13:30:11 -0700, Peter Wemm wrote: Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. I am most unhappy with this change. :-( It will be possible to have both variants, but +N is valid filename per POSIX, so obsoleted syntax can't be supported. Yes it can. If anybody wants portability beyond FreeBSD, they'll be using sort ./+N for their filenames. How many successful widely distributed OS's are there that does not allow sort +N as a numeric argument by default? (I'm sure somebody can dig up an obscure linux distribution or some microcontroller OS or something, I'm talking about something on the scale of redhat or solaris or something) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Alexander Kabaev wrote: On Tue, 24 Sep 2002 16:07:39 -0500 (CDT) Mike Silbersack [EMAIL PROTECTED] wrote: On Tue, 24 Sep 2002, Craig Rodrigues wrote: On Tue, Sep 24, 2002 at 02:05:08PM -0500, Mike Silbersack wrote: Ok, I fixed lorder.sh, and made gcc again from clean with Alexander's patch. No change, I still see the same segmentation fault. Alexander, how can I easily build gcc with full debugging symbols? That might make the backtrace more useful for you. cd /usr/src/gnu/usr.bin/cc CFLAGS=-g STRIP= make clean all install Always worked for me. -- Alexander Kabaev Yep, STRIP= was the necessary trick, I didn't realize that install -s meant strip. :) As to your patch... it turns out that I wasn't using it. I've been testing with make buildkernel, which uses the copy of gcc built by your last buildworld, not a more recent manual build of gcc. Hence, I've been testing the wrong version. I'll go ahead and run a full buildworld before testing again. Sorry about my poor testing practices. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Bill Fenner wrote: Here's my suggested fix: @@ -0,0 +1,8 @@ +/* + * Tell GNU sort(1) to implement the obsolete +1 -0 syntax even though + * it has been removed from the version of POSIX that the rest of + * the system conforms to. + */ +int posix2_version(void) { + return 0; +} Try something like this: #include stdlib.h #include unistd.h int posix2_version(void) { if (getenv(POSIX_ME_HARDER) || getenv(POSIXLY_CORRECT)) return _POSIX2_VERSION; else return 0; } Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Tue, Sep 24, 2002 at 14:39:01 -0700, Peter Wemm wrote: Bill Fenner wrote: Here's my suggested fix: +} Try something like this: If you want something like this, here is less broken way: --- lib/posixver.c.bak Fri Jun 7 11:24:45 2002 +++ lib/posixver.c Wed Sep 25 01:42:01 2002 @@ -43,7 +43,7 @@ int posix2_version (void) { - long int v = _POSIX2_VERSION; + long int v = 199209 /* XXX: _POSIX2_VERSION */; char const *s = getenv (_POSIX2_VERSION); if (s *s) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Tue, 24 Sep 2002 14:09:31 -0700, Bill Fenner [EMAIL PROTECTED] said: When's the first time the FreeBSD sort(1) man page mentioned that this syntax was deprecated? Can we at least start from there? It does not appear to have ever been properly documented. I don't object to maintaining backwards compatibility for a few more releases (even if the application writers are the ones at fault), since many more people read the manual pages than read the Standard. However, I would point out that this isn't the first time we broke a traditional syntax in favor of reducing restrictions on argument names: see the recent history of chown(8). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Tue, 24 Sep 2002 14:26:43 -0700, Peter Wemm [EMAIL PROTECTED] said: Closed payware standards do not count as 'fair warning'. I still have never been able to see a posix standard. Go to a library. Or go to http://www.opengroup.org/ and register for free on-line access. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
Nope, still getting it. I was able to reproduce the crash with your config file and unpatched GCC, however crash does not happen when I use the patch. Are you using make buildkernel or old config/make method? options IPSEC_ESP That is killing it. If I comment out that option, I get past that initial mkdep. By adding or removing configuration options, you change the exact layout of the string buffer in CPP0 and this prevents crash from happening. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
I think a lot of people would be happier if we could maintain backwards compatability (and document the fact that they're extremely obsolete) for a few more releases. Despite the fact that the main UNIX reference that I use was published in 1984, I don't actually want everything to stay the same forever. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
At 6:02 PM -0400 9/24/02, Garrett Wollman wrote: On Tue, 24 Sep 2002, Bill Fenner [EMAIL PROTECTED] said: When's the first time the FreeBSD sort(1) man page mentioned that this syntax was deprecated? Can we at least start from there? It does not appear to have ever been properly documented. I don't object to maintaining backwards compatibility for a few more releases (even if the application writers are the ones at fault), since many more people read the manual pages than read the Standard. However, I would point out that this isn't the first time we broke a traditional syntax in favor of reducing restrictions on argument names: see the recent history of chown(8). In the case of 'sort', I would rather see us ease into the change a bit more. We already have enough going on with 5.0-current that we don't need the extra excitement of this particular change. I can readily live with the fact that 5.0-release will not be 100% posix compliant. I know I have all kinds of scripts squirreled away which have 'sort +n' commands in them, and I have zero real files that are named +n. This change gives me nothing but broken scripts, and I would rather see us have an almost posix sort, and with the option to set an environment variable to remove support for +N. That way, the people who *want* to debug a bunch of scripts can set that environment variable, instead of forcing the rest of us to run around setting an environment variable to protect us from broken scripts. In some sense I don't mind the change, but I really think we are now past the point where we can keep throwing incompatible changes into 5.0-release. We have enough broken ports on 5.0-current, we do not need more incompatible changes to break even more ports to give us even more work to do. Just my 2 cents... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Garrett Wollman wrote: On Tue, 24 Sep 2002 14:09:31 -0700, Bill Fenner [EMAIL PROTECTED] s aid: When's the first time the FreeBSD sort(1) man page mentioned that this syntax was deprecated? Can we at least start from there? It does not appear to have ever been properly documented. I don't object to maintaining backwards compatibility for a few more releases (even if the application writers are the ones at fault), since many more people read the manual pages than read the Standard. However, I would point out that this isn't the first time we broke a traditional syntax in favor of reducing restrictions on argument names: see the recent history of chown(8). While this is true, consider that rev 1.1 of chown.8 says: COMPATIBILITY Previous versions of the chown utility used the dot (``.'') character to distinguish the group name. This has been changed to be a colon (``:'') character so that user and group names may contain the dot character. revision 1.1 date: 1994/05/26 05:22:22; author: rgrimes; state: Exp; It's also true that this was widely known and the transition was mostly orderly. We didn't turn it off one night as a side effect of another change that broke even our own world builds. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
Garrett Wollman wrote: On Tue, 24 Sep 2002 14:26:43 -0700, Peter Wemm [EMAIL PROTECTED] said: Closed payware standards do not count as 'fair warning'. I still have never been able to see a posix standard. Go to a library. Or go to http://www.opengroup.org/ and register for free on-line access. The 1992 version hasn't been available online since 1992. I hadn't realized that the opengroup and posix stuff had unified. I'd always thought of the opengroup stuff as SVID-on-steorids (System V Interface Definition, as it was once called). Is the posix 1992 version available? The local library doesn't have anything even remotely like this. -GAWollman Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
From: [EMAIL PROTECTED] (Bill Fenner) Date: Tue 24 Sep, 2002 Subject: Re: Who broke sort(1) ? When's the first time the FreeBSD sort(1) man page mentioned that this syntax was deprecated? Can we at least start from there? I echo this sentiment. Ideally, two 4.x releases would document something as deprecated before it actually broke in 5.0 (but preferably it still wouldn't break by default). Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses We're kind of stupid that way. *munch* *munch*and endorses FreeBSD -- http://www.calvinandhobbes.com http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 24 15:20:46 PDT 2002 -- Kernel build for GENERIC completed on Tue Sep 24 15:51:12 PDT 2002 -- Kernel build for LINT started on Tue Sep 24 15:51:12 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/coda/coda_venus.c: In function `venus_ioctl': /h/des/src/sys/coda/coda_venus.c:277: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_venus.c:292: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_venus.c: In function `venus_readlink': /h/des/src/sys/coda/coda_venus.c:380: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_venus.c: In function `venus_readdir': /h/des/src/sys/coda/coda_venus.c:637: warning: cast from pointer to integer of different size *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On 2002-09-24 13:30, Peter Wemm [EMAIL PROTECTED] wrote: Oh man, this is going to suck. There are thousands and thousands of third party scripts that use +n syntax. And ports. Lots of them. Dozens of them :( I just noticed that textproc/ispell doesn't work anymore for me. More will appear later, I'm sure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
From: [EMAIL PROTECTED] (Garrett Wollman) Date: Tue 24 Sep, 2002 Subject: Re: Who broke sort(1) ? I don't object to maintaining backwards compatibility for a few more releases (even if the application writers are the ones at fault), Umm, their fault may simply have been that they wrote the code back when it was correct and/or the only way... The author may no longer even be around to maintain the product, even if the product still exists. That's what backwards compatibility is about. I'm pretty sure Solaris will continue to support +POS in /usr/bin/sort for years to come, even though it _is_ marked as (obsolete) in the manual page. Personally, I've never had reason to unwire it from my fingers. I have less qualms about removing backward compatibility for behaviour that was only ever accidental. Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses We're kind of stupid that way. *munch* *munch*and endorses FreeBSD -- http://www.calvinandhobbes.com http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
From: [EMAIL PROTECTED] (Peter Wemm) Date: Tue 24 Sep, 2002 Subject: Re: Who broke sort(1) ? How many successful widely distributed OS's are there that does not allow sort +N as a numeric argument by default? (I'm sure somebody can dig up an obscure linux distribution or some microcontroller OS or something, I'm talking about something on the scale of redhat or solaris or something) Ditto for expr -1 + 1... Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses We're kind of stupid that way. *munch* *munch*and endorses FreeBSD -- http://www.calvinandhobbes.com http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
Alexander Kabaev wrote: On Tue, 24 Sep 2002 00:00:45 -0700 Crist J. Clark [EMAIL PROTECTED] wrote: Not too sure about that. Now I'm getting SIGSEGV again, You are right. There was a stupid mistake in the latest version, sorry. Could you try yet another patch? http://people.freebsd.org/~kan/gcc-cpp.diff FYI, I saw the same error as Crist when building -current under 4.6, and with your patch, the buildworld/buildkernel succeeded. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Who broke sort(1) ?
On Tue, 24 Sep 2002, Peter Wemm wrote: Garrett Wollman wrote: On Tue, 24 Sep 2002 14:26:43 -0700, Peter Wemm [EMAIL PROTECTED] said: Closed payware standards do not count as 'fair warning'. I still have never been able to see a posix standard. Go to a library. Or go to http://www.opengroup.org/ and register for free on-line access. The 1992 version hasn't been available online since 1992. I hadn't realized that the opengroup and posix stuff had unified. I'd always thought of the opengroup stuff as SVID-on-steorids (System V Interface Definition, as it was once called). Is the posix 1992 version available? The local library doesn't have anything even remotely like this. A 1991 draft version is still available at: http://www.funet.fi/pub/doc/posix/posix Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -mcpu=pentiumpro still evil?
On Tue, 24 Sep 2002, Mike Silbersack wrote: Yep, STRIP= was the necessary trick, I didn't realize that install -s meant strip. :) As to your patch... it turns out that I wasn't using it. I've been testing with make buildkernel, which uses the copy of gcc built by your last buildworld, not a more recent manual build of gcc. Hence, I've been testing the wrong version. I'll go ahead and run a full buildworld before testing again. Sorry about my poor testing practices. Mike Silby Silbersack Ok, now that I tested properly, I can confirm that your generation 3 patch seems to solve the problem here. Please commit it asap! Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
From: [EMAIL PROTECTED] (Bruce Evans) Date: Wed 25 Sep, 2002 Subject: Re: Who broke sort(1) ? On Tue, 24 Sep 2002, Peter Wemm wrote: A 1991 draft version is still available at: http://www.funet.fi/pub/doc/posix/posix Nice directory listing. s/http/ftp/ and s/www/ftp/ and I get another directory listing. A further s/posix\/posix/posix/ and I get: ftp get README - remote: README 227 Entering Passive Mode (193,166,3,2,200,254) 150 Opening BINARY mode data connection for /pub/doc/posix/README (77 bytes). The file `index' contains a short summary of the contents of this directory. 226 Transfer complete. 77 bytes received in 0.24 seconds (0.31 KB/s) But: -rw-r--r-- 1 root csc 107951 May 30 1992 index.tar.Z I could try harder. If it turns out to be legal, it might even be old enough by now to be useful... ;-) Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses We're kind of stupid that way. *munch* *munch*and endorses FreeBSD -- http://www.calvinandhobbes.com http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Wed, Sep 25, 2002 at 12:06:45AM +, attila! wrote: However, I do object to GNU's heavy handed removal of a flag which is in extensive use. I don't have a problem with the new syntax, but leave the old one intact -k, --key=POS1[,POS2] start a key at POS1, end it at POS 2 GNU's heavy handed removal? According to Bill Fenner the removal is mandated by POSIX. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel broken(?) at vfs_mount.c
cc1: warnings being treated as errors /usr/src/sys/kern/vfs_mount.c: In function `checkdirs': /usr/src/sys/kern/vfs_mount.c:1141: warning: implicit declaration of function `vrefcnt' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel broken(?) at vfs_mount.c
cc1: warnings being treated as errors /usr/src/sys/kern/vfs_mount.c: In function `checkdirs': /usr/src/sys/kern/vfs_mount.c:1141: warning: implicit declaration of function `vrefcnt' Oops, I commited this file before I commited a dependency. Please cvsup again. Specifically, you need the new vnode.h and vfs_subr.c Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Sep 24 22:18:51 PDT 2002 -- === xe cc1: warnings being treated as errors /local0/scratch/des/src/sys/kern/vfs_mount.c: In function `checkdirs': /local0/scratch/des/src/sys/kern/vfs_mount.c:1141: warning: implicit declaration of function `vrefcnt' *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message