headers
itojun | 1 Jun 2002 03:27

buildtools in 1.6 distribution

	maybe a stupid question...
	in 1.6 distribution, how will build tools (src/tools) be shipped?
	will they be shipped in comp.tgz, or not shipped at all? (people needs
	to build toolchain before "make build")
	i'm asking this because, in some cases, people install 1.6 and
	then partially upgrade to netbsd-current (like kernel and vmstat/
	netstat).  do we require them to build toolchain in such cases? 

itojun
Permalink | Reply | 1 comment |
headers
Jason R Thorpe | 1 Jun 2002 03:51

Re: buildtools in 1.6 distribution

On Sat, Jun 01, 2002 at 10:27:46AM +0900, itojun <at> iijlab.net wrote:

 > 	maybe a stupid question...
 > 	in 1.6 distribution, how will build tools (src/tools) be shipped?
 > 	will they be shipped in comp.tgz, or not shipped at all? (people needs
 > 	to build toolchain before "make build")
 > 	i'm asking this because, in some cases, people install 1.6 and
 > 	then partially upgrade to netbsd-current (like kernel and vmstat/
 > 	netstat).  do we require them to build toolchain in such cases? 

Yes.  The toolchain is associated with the source tree you're building,
not the system you're running.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
Ben Harris | 1 Jun 2002 23:50
Picon

Re: gcc-current and warnings in bin/sh

In article <200205311924.PAA23286 <at> Sparkle.Rodents.Montreal.QC.CA> you write:
>> /u1/netbsd/src/bin/sh/eval.c:641: warning: comparison is always true due to limited range of data type
>> /u1/netbsd/src/bin/sh/eval.c:644: warning: comparison is always true due to limited range of data type
>[...]
>
>> -		if (varflag && is_name(*p)) {
>> +		int c;
>> +		if (varflag && is_name((c = *p))) {
>[...]
>> -			} while (is_in_name(*p));
>> +			} while (is_in_name((c = *p)));
>
>Quite aside from the problem itself, which another message makes me
>think has already been fixed, I'd remark that you don't need another
>variable for something like this; a cast should be quite enough:

I don't know about GCC-current, but in GCC 2.95.3 a cast doesn't work.  See
doc/HACKS, entry "gcc-unsigned-compare".

--

-- 
Ben Harris                                                   <bjh21 <at> netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>
Permalink | Reply | 2 comments |
headers
itojun | 2 Jun 2002 16:37

finger/fingerd with non-ASCII chars

	if you are interested in finger/fingerd support for non-ASCII
	chars, please take a look at PR bin/17142 - I would like to know
	about prior art/commonly used options for this.

itojun
Permalink | Reply | 0 comments |
headers
der Mouse | 2 Jun 2002 19:34
Picon

Re: gcc-current and warnings in bin/sh

>>> -		if (varflag && is_name(*p)) {
>>> +		int c;
>>> +		if (varflag && is_name((c = *p))) {

>> [...] you don't need another variable for something like this; a
>> cast should be quite enough:

> I don't know about GCC-current, but in GCC 2.95.3 a cast doesn't
> work.  See doc/HACKS, entry "gcc-unsigned-compare".

That's about enums, and then only when building with -fshort-enums.
Does it affect chars too, then?  (Also, could some language lawyer
check whether this really is permitted behaviour, and if not, file a
bug report with the gcc folks?  I _think_ we have a person or two on
here who's got a copy of The Standard....)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 1 comment |
headers
Ben Harris | 3 Jun 2002 00:42
Picon

Re: gcc-current and warnings in bin/sh

In article <200206021734.NAA13517 <at> Sparkle.Rodents.Montreal.QC.CA> you write:
>>>> -		if (varflag && is_name(*p)) {
>>>> +		int c;
>>>> +		if (varflag && is_name((c = *p))) {
>
>>> [...] you don't need another variable for something like this; a
>>> cast should be quite enough:
>
>> I don't know about GCC-current, but in GCC 2.95.3 a cast doesn't
>> work.  See doc/HACKS, entry "gcc-unsigned-compare".
>
>That's about enums, and then only when building with -fshort-enums.
>Does it affect chars too, then?

ISTR that the code in question only cares about the characteristics of the
type in question, not its name.

>(Also, could some language lawyer
>check whether this really is permitted behaviour, and if not, file a
>bug report with the gcc folks?  I _think_ we have a person or two on
>here who's got a copy of The Standard....)

I don't think the standard says anything about what warnings the compiler
may emit.  The code is obviously valid even without the cast.

--

-- 
Ben Harris                                                   <bjh21 <at> netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>
(Continue reading)

Permalink | Reply | 0 comments |
headers
itojun | 3 Jun 2002 11:41

html manpage policy

	i've noticed /usr/share/man/html*.  it is listed in
	/etc/mtree/NetBSD.dist, however, html manpages are not generated/
	installed.  distrib/sets/lists do not have them either.  what is
	the status?

itojun
Permalink | Reply | 0 comments |
headers
Martin Mačok | 3 Jun 2002 13:41
Picon

man getopt_long bug

NetBSD 1.6_BETA1

man getopt_long

substitute "struct options" with "struct option"

--

-- 
         Martin Mačok                 http://underground.cz/
   martin.macok <at> underground.cz        http://Xtrmntr.org/ORBman/
Permalink | Reply | 2 comments |
headers
Julio Merino | 3 Jun 2002 14:00

Re: man getopt_long bug

On Mon, Jun 03, 2002 at 01:41:24PM +0200, Martin Ma?ok wrote:
> NetBSD 1.6_BETA1
> 
> man getopt_long
> 
> substitute "struct options" with "struct option"

Here you have the patch. You should have sended this as a pr, I think.

Index: getopt_long.3
===================================================================
RCS file: /cvsroot/basesrc/lib/libc/stdlib/getopt_long.3,v
retrieving revision 1.7
diff -u -u -r1.7 getopt_long.3
--- getopt_long.3	2002/02/07 09:24:06	1.7
+++ getopt_long.3	2002/06/03 11:59:14
 <at>  <at>  -44,7 +44,7  <at>  <at> 
 .Sh SYNOPSIS
 .Fd #include \*[Lt]getopt.h\*[Gt]
 .Ft int
-.Fn getopt_long "int argc" "char * const *argv" "const char *optstring" "struct options *long options"
"int *index"
+.Fn getopt_long "int argc" "char * const *argv" "const char *optstring" "struct option *long options"
"int *index"
 .Sh DESCRIPTION
 The
 .Fn getopt_long

--

-- 
Of course it runs NetBSD - http://www.netbsd.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Klausner | 3 Jun 2002 14:02
Picon

Re: man getopt_long bug

On Mon, Jun 03, 2002 at 01:41:24PM +0200, Martin Ma?ok wrote:
> NetBSD 1.6_BETA1
> 
> man getopt_long
> 
> substitute "struct options" with "struct option"

Fixed, I'll send a pull-up request.

Bye,
 Thomas

--

-- 
Thomas Klausner - wiz <at> danbala.tuwien.ac.at
Intolerance is the last defense of the insecure.
Permalink | Reply | 0 comments |

Gmane