Re: trouble building XFree86-4-Server under yesterday's current

[Vallo Kallaste]

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

[Garrett Wollman]

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

[Crist J. Clark]

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

[Dag-Erling Smorgrav]

--
 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.

[walt]

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

[Andrey A. Chernov]

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) ?

[Andrey A. Chernov]

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

[walt]

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

[Wesley Morgan]

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

[Fergus Cameron]

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

[Vallo Kallaste]

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

[Alexander Kabaev]

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

[Dag-Erling Smorgrav]

--
 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?

[Alexander Kabaev]

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

[Alexander Kabaev]

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?

[Mike Silbersack]

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?

[Mike Silbersack]

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?

[Alexander Kabaev]

 
 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

[Marc Recht]

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

[Poul-Henning Kamp]

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

[Poul-Henning Kamp]

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

[Nate Lawson]

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

[Robert Watson]

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?

[walt]

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

[Marc Recht]

 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

[Marc Recht]

 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

[Andrey A. Chernov]

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

[Robert Watson]

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?

[Mike Silbersack]

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?

[Craig Rodrigues]

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

[Wesley Morgan]

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

[Kris Kennaway]

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'

[walt]

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

[Andrey A. Chernov]

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) ?

[Peter Wemm]

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) ?

[Bill Fenner]

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.

[Giorgos Keramidas]

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) ?

[Andrey A. Chernov]

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) ?

[Terry Lambert]

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

[justin]

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) ?

[Andrey A. Chernov]

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

[Crist J. Clark]

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) ?

[Bill Fenner]

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) ?

[Garrett Wollman]

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?

[Mike Silbersack]

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) ?

[Bill Fenner]

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) ?

[Andrey A. Chernov]

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) ?

[Bill Fenner]

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?

[Alexander Kabaev]

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) ?

[Peter Wemm]

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) ?

[Peter Wemm]

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?

[Mike Silbersack]

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) ?

[Peter Wemm]

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) ?

[Andrey A. Chernov]

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) ?

[Garrett Wollman]

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) ?

[Garrett Wollman]

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

[Alexander Kabaev]

 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) ?

[Bill Fenner]

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) ?

[Garance A Drosihn]

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) ?

[Peter Wemm]

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) ?

[Peter Wemm]

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) ?

[Mark Valentine]

 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

[Dag-Erling Smorgrav]

--
 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) ?

[Giorgos Keramidas]

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) ?

[Mark Valentine]

 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) ?

[Mark Valentine]

 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

[Lars Eggert]

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) ?

[Bruce Evans]

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?

[Mike Silbersack]

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) ?

[Mark Valentine]

 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) ?

[Steve Kargl]

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

[walt]

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

[Jeff Roberson]

 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

[Dag-Erling Smorgrav]

--
 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