Re: chgrp broken on alpha systems

[Warner Losh]

In message <[EMAIL PROTECTED]> Terry Lambert writes:
: If cross-compilation actually worked, the people causing
: the problems for the Alpha would be able to test the
: build, with only their x86 hardware.

I think that's why you are seeing so many people trying to make it
work :-)

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

Absolutely. People *are* working on getting that fixed.


On Mon, 9 Jul 2001, Terry Lambert wrote:

> Matthew Jacob wrote:
> > 
> > Yes, I've actually been massaging a few of those- glad somebody's on
> > it. I'll come on out to Concord if you you need a hand It's
> > sometimes hard to keep -current up on an alpha long enough for a
> > complete buildworld
> 
> If cross-compilation actually worked, the people causing
> the problems for the Alpha would be able to test the
> build, with only their x86 hardware.
> 
> Food for thought...
> 
> -- Terry
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Terry Lambert]

Matthew Jacob wrote:
> 
> Yes, I've actually been massaging a few of those- glad somebody's on
> it. I'll come on out to Concord if you you need a hand It's
> sometimes hard to keep -current up on an alpha long enough for a
> complete buildworld

If cross-compilation actually worked, the people causing
the problems for the Alpha would be able to test the
build, with only their x86 hardware.

Food for thought...

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Dag-Erling Smorgrav]

Bruce Evans <[EMAIL PROTECTED]> writes:
> On 8 Jul 2001, Dag-Erling Smorgrav wrote:
> > My -DNOPERL build broke in games/fortune in the "building everything"
> > phase because the Alpha compiler tried to use the i386 strfile.o that
> > was left over from the bootstrap phase.
> This shouldn't happen.  The bootstrap phase builds in a host-specific
> hierarchy in the obj tree.  The alpha compiler shouldn't go near this
> hierarchy.

I'll try again - it may have been a polluted source tree.  In any
case, the build got pretty far before it croaked.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Bruce Evans]

On 8 Jul 2001, Dag-Erling Smorgrav wrote:

> Mark Peek <[EMAIL PROTECTED]> writes:
> > It probably works since i386 and pc98 are similar. I'm trying an alpha
> > cross build as we speak. So far I needed to apply this patch to get
> > around having -mcpu=ev4 being fed to the i386 compiler during the
> > build tools phase.
> 
> My -DNOPERL build broke in games/fortune in the "building everything"
> phase because the Alpha compiler tried to use the i386 strfile.o that
> was left over from the bootstrap phase.

This shouldn't happen.  The bootstrap phase builds in a host-specific
hierarchy in the obj tree.  The alpha compiler shouldn't go near this
hierarchy.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Dag-Erling Smorgrav]

Mark Peek <[EMAIL PROTECTED]> writes:
> It probably works since i386 and pc98 are similar. I'm trying an alpha
> cross build as we speak. So far I needed to apply this patch to get
> around having -mcpu=ev4 being fed to the i386 compiler during the
> build tools phase.

My -DNOPERL build broke in games/fortune in the "building everything"
phase because the Alpha compiler tried to use the i386 strfile.o that
was left over from the bootstrap phase.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Cross compiling (was Re: chgrp broken on alpha systems)

[Warner Losh]

[cc's trimed]

In message  Mark Peek writes:
: It probably works since i386 and pc98 are similar. I'm trying an 
: alpha cross build as we speak. So far I needed to apply this patch to 
: get around having -mcpu=ev4 being fed to the i386 compiler during the 
: build tools phase.

Sure makes some odd pathnames, but so far it seems to be working for
me.  I waited until I was into stage 4 to send this message.  When I
started seeing command lines like:

cc -nostdinc -O -pipe -mcpu=ev4 -mcpu=ev4 -I/home/imp/FreeBSD/src/lib/libmd 
-I/usr/obj/alpha/home/imp/FreeBSD/src/i386/usr/include  -c 
/home/imp/FreeBSD/src/lib/libmd/sha0c.c -o sha0c.o

which tells me that this is a good patch.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Mark Peek]

At 1:49 PM -0600 7/8/01, Warner Losh wrote:
>In message <[EMAIL PROTECTED]> "David O'Brien" writes:
>: On Sun, Jul 08, 2001 at 07:03:26PM +0200, Dag-Erling Smorgrav wrote:
>: > Bruce Evans <[EMAIL PROTECTED]> writes:
>: > > [explaining how to build an LP64 world on i386]
>: >
>: > I just had a major "doh" moment...
>: >
>: > # cd /usr/src
>: > # make MACHINE_ARCH=alpha buildworld >& /var/log/world.alpha &
>: > [1] 13655
>: >
>: > Ought to catch any Alpha WARNS fuckups.  Or did I overlook something?
>:
>: It doesn't work anymore.
>
>What's the misfunction?  I do the above with MACHINE_ARCH=pc98 on my
>i386 box all the time to build pc98 worlds.


It probably works since i386 and pc98 are similar. I'm trying an 
alpha cross build as we speak. So far I needed to apply this patch to 
get around having -mcpu=ev4 being fed to the i386 compiler during the 
build tools phase.


Index: Makefile.inc1
===
RCS file: /cvs/freebsd/src/Makefile.inc1,v
retrieving revision 1.205
diff -u -r1.205 Makefile.inc1
--- Makefile.inc1   2001/06/14 01:35:22 1.205
+++ Makefile.inc1   2001/07/08 20:06:34
@@ -185,6 +185,7 @@
  # build-tool stage
  TMAKEENV= MAKEOBJDIRPREFIX=${OBJTREE} \
INSTALL="sh ${.CURDIR}/tools/install.sh" \
+   MACHINE_ARCH=`uname -m` \
PATH=${TMPPATH}
  TMAKE=${TMAKEENV} ${MAKE} -f Makefile.inc1


Mark

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Warner Losh]

In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: On Sun, Jul 08, 2001 at 07:03:26PM +0200, Dag-Erling Smorgrav wrote:
: > Bruce Evans <[EMAIL PROTECTED]> writes:
: > > [explaining how to build an LP64 world on i386]
: > 
: > I just had a major "doh" moment...
: > 
: > # cd /usr/src
: > # make MACHINE_ARCH=alpha buildworld >& /var/log/world.alpha &
: > [1] 13655
: > 
: > Ought to catch any Alpha WARNS fuckups.  Or did I overlook something?
: 
: It doesn't work anymore.

What's the misfunction?  I do the above with MACHINE_ARCH=pc98 on my
i386 box all the time to build pc98 worlds.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Sun, Jul 08, 2001 at 07:03:26PM +0200, Dag-Erling Smorgrav wrote:
> Bruce Evans <[EMAIL PROTECTED]> writes:
> > [explaining how to build an LP64 world on i386]
> 
> I just had a major "doh" moment...
> 
> # cd /usr/src
> # make MACHINE_ARCH=alpha buildworld >& /var/log/world.alpha &
> [1] 13655
> 
> Ought to catch any Alpha WARNS fuckups.  Or did I overlook something?

It doesn't work anymore.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Dag-Erling Smorgrav]

Bruce Evans <[EMAIL PROTECTED]> writes:
> [explaining how to build an LP64 world on i386]

I just had a major "doh" moment...

# cd /usr/src
# make MACHINE_ARCH=alpha buildworld >& /var/log/world.alpha &
[1] 13655

Ought to catch any Alpha WARNS fuckups.  Or did I overlook something?

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Bruce Evans]

On Sat, 7 Jul 2001, David O'Brien wrote:

> On Sat, Jul 07, 2001 at 01:02:28PM -0700, Matthew Jacob wrote:
> > 
> > 
> > On Sat, 7 Jul 2001, David O'Brien wrote:
> > 
> > > On Sat, Jul 07, 2001 at 11:54:26AM -0700, Matthew Jacob wrote:
> > > >
> > > >
> > > > On Sat, 7 Jul 2001, David O'Brien wrote:
> > > >
> > > > > On Fri, Jul 06, 2001 at 03:08:04PM +1000, Peter Jeremy wrote:
> > > > > >   i386 type Alpha type
> > > > > > clock_t unsigned long   int
> > > > >
> > > > > We could make these the same (not sure why they aren't).

No good reason.  I think "unsigned long" is used on i386's because that
was the largest type.  This was apparently considered to be too large
on alphas, so it was changed to a 32 bit type.  Changing it from a signed
type to an unsigned type was just a pessimization of its range.  With the
alpha pessimizations of the scale factors (_BSD_CLOCKS_PER_SEC_ = 100
and _BSD_CLK_TCK_ = 100), the range of a 31-effective-bits clock_t is
24.855 days.  A 32-bit unsigned clock_t would have a range of 49.710
days.  POSIX.1 only requires a range of 1 day.

> > > > because on alpha long == 64 bits
> > >
> > > What about the otherway around??  Like use "int" or "unsigned int" on
> > > both.
> > 
> > Let's use 64 bits for both.
> > 
> > You're retirement has been put off to 2043 at least...

clock_t has nothing to do with calendar times.

> I don't know what clock_t is used for (kernel version of time_t?).
> But the general agreement was to leave time as a 32-bit value on the
> Alpha in order to match (1) FreeBSD/i386 and (2) OSF/1,Digital Unix,Tru64.

It is used (entirely outside of the kernel) for the following interfaces:

clock_t clock(void);(ISO C)
clock_t times(struct tms *);(POSIX.1)
struct tms members:
clock_t tms_utime
clock_t tms_stime
clock_t tms_cutime
clock_t tms_cstime

See clocks.7 for more details about whey these interfaces are currently
not useful.  (To be as useful as getrusage(), CLOCKS_PER_SEC must be at
least 10^6.  This gives at least 86.4e9 "ticks" per day, so clock_t must
have at least 37 bits.)

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Bruce Evans]

On 8 Jul 2001, Dag-Erling Smorgrav wrote:

> "David O'Brien" <[EMAIL PROTECTED]> writes:
> > OR build a 64-bit long (LP64) x86 gcc and test compile with that also.
> > BDE found *lots* of 64-bit dirty code using this technique.
> 
> Mind revealing how that's done?

Compiling [g]cc with -DLONG_TYPE_SIZE=64 gives an I32L64P32 compiler
(you can also try setting CHAR_TYPE_SIZE through LONG_DOUBLE_TYPE_SIZE
to unusual values to get a more exotic compiler).  Then fix some build
issues (mainly with quad functions in libc; I just hack around these
by copying the 3 relevant 32-bit quad objects to the libc obj directory),
and fix all the unportable code (I fixed enough to bootstrap but haven't
committed everything.  I build the world on a normal 32-bit i386 using
something like:

CC='cc -D_LARGE_LONG' \
DESTDIR=/c/z/root \
LONG_TYPE_SIZE=64 \
MAKEOBJDIRPREFIX=/c/z/obj \
time -l make -s world > /tmp/world.out 2>&1

(-D_LARGE_LONG is a wrong hack.  It affects , but 
should only be affected for the target.).

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Dag-Erling Smorgrav]

"David O'Brien" <[EMAIL PROTECTED]> writes:
> OR build a 64-bit long (LP64) x86 gcc and test compile with that also.
> BDE found *lots* of 64-bit dirty code using this technique.

Mind revealing how that's done?

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[John Polstra]

In article <[EMAIL PROTECTED]>, David O'Brien
<[EMAIL PROTECTED]> wrote:

> I don't know what clock_t is used for (kernel version of time_t?).

It was invented by the ANSI/ISO C committee to represent CPU time.
Hardly anything uses it.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

>
> I don't know what clock_t is used for (kernel version of time_t?).
> But the general agreement was to leave time as a 32-bit value on the
> Alpha in order to match (1) FreeBSD/i386 and (2) OSF/1,Digital Unix,Tru64.
>

okay, okay, end the thread...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Sat, Jul 07, 2001 at 01:02:28PM -0700, Matthew Jacob wrote:
> 
> 
> On Sat, 7 Jul 2001, David O'Brien wrote:
> 
> > On Sat, Jul 07, 2001 at 11:54:26AM -0700, Matthew Jacob wrote:
> > >
> > >
> > > On Sat, 7 Jul 2001, David O'Brien wrote:
> > >
> > > > On Fri, Jul 06, 2001 at 03:08:04PM +1000, Peter Jeremy wrote:
> > > > > i386 type Alpha type
> > > > > clock_t   unsigned long   int
> > > >
> > > > We could make these the same (not sure why they aren't).
> > >
> > > because on alpha long == 64 bits
> >
> > What about the otherway around??  Like use "int" or "unsigned int" on
> > both.
> 
> Let's use 64 bits for both.
> 
> You're retirement has been put off to 2043 at least...

I don't know what clock_t is used for (kernel version of time_t?).
But the general agreement was to leave time as a 32-bit value on the
Alpha in order to match (1) FreeBSD/i386 and (2) OSF/1,Digital Unix,Tru64.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Sat, 7 Jul 2001, David O'Brien wrote:

> On Sat, Jul 07, 2001 at 11:54:26AM -0700, Matthew Jacob wrote:
> >
> >
> > On Sat, 7 Jul 2001, David O'Brien wrote:
> >
> > > On Fri, Jul 06, 2001 at 03:08:04PM +1000, Peter Jeremy wrote:
> > > >   i386 type Alpha type
> > > > clock_t unsigned long   int
> > >
> > > We could make these the same (not sure why they aren't).
> >
> > because on alpha long == 64 bits
>
> What about the otherway around??  Like use "int" or "unsigned int" on
> both.

Let's use 64 bits for both.

You're retirement has been put off to 2043 at least...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Sat, Jul 07, 2001 at 11:54:26AM -0700, Matthew Jacob wrote:
> 
> 
> On Sat, 7 Jul 2001, David O'Brien wrote:
> 
> > On Fri, Jul 06, 2001 at 03:08:04PM +1000, Peter Jeremy wrote:
> > > i386 type Alpha type
> > > clock_t   unsigned long   int
> >
> > We could make these the same (not sure why they aren't).
> 
> because on alpha long == 64 bits

What about the otherway around??  Like use "int" or "unsigned int" on
both.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Sat, 7 Jul 2001, David O'Brien wrote:

> On Fri, Jul 06, 2001 at 03:08:04PM +1000, Peter Jeremy wrote:
> >   i386 type Alpha type
> > clock_t unsigned long   int
>
> We could make these the same (not sure why they aren't).

because on alpha long == 64 bits

>
> > ptrdiff_t   int long
> > size_t  unsigned intunsigned long
> > ssize_t int long
> > *physaddr   { int r[1]; }   { long r[1]; }
> > vm_offset_t unsigned intunsigned long
> > vm_pindex_t unsigned intunsigned long
> > vm_size_t   unsigned intunsigned long
> > intfptr_t   int long
> > uintfptr_t  unsigned intunsigned long
>
> these also since long == int on x86.  Then if one build a 64-bit long
> i386 compiler (BDE does this) one could also test 64-bit issues on an
> i386 box almost as well as on an Alpha.
>
> --
> -- David  ([EMAIL PROTECTED])
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Fri, Jul 06, 2001 at 07:40:59AM -0700, Mark Peek wrote:
> I had the same idea last night. I modified my PowerPC cross-compiler 
> "port" to produce an Alpha version. This is based on the lang/gcc295 
> port so it contains the FreeBSD patches for things like -Wformat. For 
> sake of example, I only worried about the compiler and not linking 
> since that would require compiling or downloading the libs for an 
> Alpha.

I think a LP64 i386 compiler would be more useful as one should be able
to make it thru a complete `make buildworld' with it.

BDE does this by setting "_LARGE_LONG" and "LONG_TYPE_SIZE=64".  See
/usr/src/gnu/usr.bin/cc/Makefile.inc.

-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Fri, Jul 06, 2001 at 04:37:43PM +1000, Peter Jeremy wrote:
> >On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
> >NetBSD/alpha (same compiler, really), this produces:
> >
> >x.c: In function `func':
> >x.c:4: warning: cast from pointer to integer of different size
> >
> >It'd be *really* nice if we could add a flag where such errors could be
> >checked for and emitted for an i386 build.
> 
> David would know for certain, but I think this is messy to detect.  As
> I see it, the problem is that when casting a pointer type to an
> integer type, gcc only looks at the lengths of the types - on an i386,
> sizeof(int) == sizeof(long) == sizeof(void *), whereas on an Alpha,
> sizeof(int) != sizeof(long) == sizeof(void *).  Whilst it is possible
> to change the check so that it verifies that the integer type is
> `long' (or longer), this may cause other problems.

Correct.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Fri, Jul 06, 2001 at 03:08:04PM +1000, Peter Jeremy wrote:
> i386 type Alpha type
> clock_t   unsigned long   int

We could make these the same (not sure why they aren't).

> ptrdiff_t int long
> size_tunsigned intunsigned long
> ssize_t   int long
> *physaddr { int r[1]; }   { long r[1]; }
> vm_offset_t   unsigned intunsigned long
> vm_pindex_t   unsigned intunsigned long
> vm_size_t unsigned intunsigned long
> intfptr_t int long
> uintfptr_tunsigned intunsigned long

these also since long == int on x86.  Then if one build a 64-bit long
i386 compiler (BDE does this) one could also test 64-bit issues on an
i386 box almost as well as on an Alpha.

-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Thu, Jul 05, 2001 at 07:13:20PM -0700, Kris Kennaway wrote:
> Yes, people need to be more careful when enabling WARNS and not do it
> until they've positively tested it on alpha.

OR build a 64-bit long (LP64) x86 gcc and test compile with that also.
BDE found *lots* of 64-bit dirty code using this technique.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Fri, Jul 06, 2001 at 06:59:27PM +0200, Dag-Erling Smorgrav wrote:
> "David O'Brien" <[EMAIL PROTECTED]> writes:
> > People are making more and more mistakes that break the Alpha build.
> > We will soon have two more arches.
> 
> ...which won't really make much difference, as 99% of the difference
> in userland code is integer and pointer sizes, so for all practical
> purposes (when working on userland code) Alpha, IA64 and Sparc64 will
> be equivalent, as will i386 and PowerPC.

Not fully -- PowerPC and sparc64 are big-endian.  So there could be
warning issues with the change in endian'ness that i386 and Alpha do not
show.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Dag-Erling Smorgrav]

"David O'Brien" <[EMAIL PROTECTED]> writes:
> People are making more and more mistakes that break the Alpha build.
> We will soon have two more arches.

...which won't really make much difference, as 99% of the difference
in userland code is integer and pointer sizes, so for all practical
purposes (when working on userland code) Alpha, IA64 and Sparc64 will
be equivalent, as will i386 and PowerPC.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

Yes!


On Fri, 6 Jul 2001, Mark Peek wrote:

> At 4:37 PM +1000 7/6/01, Peter Jeremy wrote:
> >Another random thought:  If it was easier to build/install a
> >cross-platform version of gcc, it might be easier to convince
> >developers to at least check that compiling on different platforms
> >works before committing.
>
> Peter,
> I had the same idea last night. I modified my PowerPC cross-compiler
> "port" to produce an Alpha version. This is based on the lang/gcc295
> port so it contains the FreeBSD patches for things like -Wformat. For
> sake of example, I only worried about the compiler and not linking
> since that would require compiling or downloading the libs for an
> Alpha.
>
> # uname -m
> i386
> # cvs update -r1.5 chkgrp.c
> P chkgrp.c
> # make CC=alpha-gcc chkgrp.o
> alpha-gcc -O -pipe-W -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror
> -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow  -c
> chkgrp.c
> cc1: warnings being treated as errors
> chkgrp.c: In function `main':
> chkgrp.c:76: warning: passing arg 2 of `fgetln' from incompatible pointer type
> *** Error code 1
>
> Stop in /tmp/chkgrp.
> # cvs update -r1.6 chkgrp.c
> P chkgrp.c
> # make CC=alpha-gcc chkgrp.o
> alpha-gcc -O -pipe-W -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror
> -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow  -c
> chkgrp.c
>
>
> This could help prevent breakage to buildworld on other platforms
> but, of course, does not prevent runtime errors from creeping in.
>
> If there is interest in this, I could see about getting this into
> ports (after a little testing and tweaking).
>
>
> Mark
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Mark Peek]

At 4:37 PM +1000 7/6/01, Peter Jeremy wrote:
>Another random thought:  If it was easier to build/install a
>cross-platform version of gcc, it might be easier to convince
>developers to at least check that compiling on different platforms
>works before committing.

Peter,
I had the same idea last night. I modified my PowerPC cross-compiler 
"port" to produce an Alpha version. This is based on the lang/gcc295 
port so it contains the FreeBSD patches for things like -Wformat. For 
sake of example, I only worried about the compiler and not linking 
since that would require compiling or downloading the libs for an 
Alpha.

# uname -m
i386
# cvs update -r1.5 chkgrp.c
P chkgrp.c
# make CC=alpha-gcc chkgrp.o
alpha-gcc -O -pipe-W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow  -c 
chkgrp.c
cc1: warnings being treated as errors
chkgrp.c: In function `main':
chkgrp.c:76: warning: passing arg 2 of `fgetln' from incompatible pointer type
*** Error code 1

Stop in /tmp/chkgrp.
# cvs update -r1.6 chkgrp.c
P chkgrp.c
# make CC=alpha-gcc chkgrp.o
alpha-gcc -O -pipe-W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow  -c 
chkgrp.c


This could help prevent breakage to buildworld on other platforms 
but, of course, does not prevent runtime errors from creeping in.

If there is interest in this, I could see about getting this into 
ports (after a little testing and tweaking).


Mark

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

> >On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
> >NetBSD/alpha (same compiler, really), this produces:
> >
> >x.c: In function `func':
> >x.c:4: warning: cast from pointer to integer of different size
> >
> >It'd be *really* nice if we could add a flag where such errors could be
> >checked for and emitted for an i386 build.
>
> David would know for certain, but I think this is messy to detect.  As
> I see it, the problem is that when casting a pointer type to an
> integer type, gcc only looks at the lengths of the types - on an i386,
> sizeof(int) == sizeof(long) == sizeof(void *), whereas on an Alpha,
> sizeof(int) != sizeof(long) == sizeof(void *).  Whilst it is possible
> to change the check so that it verifies that the integer type is
> `long' (or longer), this may cause other problems.

Yes. Fooling around with compilers is like fooling around with a partially
loaded revolver.

I was browsing through c-typeck.c, and I don't see a really good way of doing
this other than:

  if (TREE_CODE (type) == INTEGER_TYPE
  && TREE_CODE (otype) == POINTER_TYPE
  && TYPE_PRECISION (type) != TYPE_PRECISION (otype)
  && !TREE_CONSTANT (value))
warning ("cast from pointer to integer of different size");

+ if (warn_other_precision_width && TREE_CODE (type) == INTEGER_TYPE
+ && TREE_CODE (otype) == POINTER_TYPE
+ && warn_other_precision_width != TYPE_PRECISION (otype)
+ && !TREE_CONSTANT (value))
+   warning ("pointer to integer cast would break on %d bit pointers",
+   warn_other_precision_width)


where warn_other_precision_width is set with -Wptrsize=N, where N is the width
in bits of a pointer type you want to compare it to.

>
> A further obstacle is that [u]intptr_tmaps to an [u]int on the i386
> and I don't think that gcc can tell the difference between (int) and
> (intptr_t) when applied to a pointer.

Sigh, yes.

>
> One solution would be to make [u]intptr_t a `magic' type in gcc and
> have it whinge whenever a pointer or [u]intptr_t was cast or assigned
> to anything other than a pointer or [u]intptr_t.  This is probably a
> non-trivial task in gcc and would lead to lots of false positives.

Yes.

>
> Overall, I think that making developers more aware of cross-platform
> issues,

That may or may not ever happen.

> combined with the availability of test boxes (like beast) is
> a better solution.  It's definitely unreasonable to expect all
> developers to own machines for all the target architectures.

Why not? H/W's cheap enough :-)...

>
> Another random thought:  If it was easier to build/install a
> cross-platform version of gcc, it might be easier to convince
> developers to at least check that compiling on different platforms
> works before committing.
>

All of these things are good ideas. There will still be breakage because
people will check things in with a "Oh- that's so simple, it won't break a
thing, and anyway, it compiled on my machine...". That's just such a hard
habit to break for the onesey-twosey types of changes.


-matt





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Peter Jeremy]

On 2001-Jul-05 22:22:11 -0700, Matthew Jacob <[EMAIL PROTECTED]> wrote:
>>  IMHO, the problem splits into two categories:
>> Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
>> and the i386. 
>
>Yes.  This tends to be caught by the alpha compiler but the i386.
>It'd be nice if there were a -Wpun. For example:
>
>x.c:
>
>int
>func(char *p)
>{
>int j = (int) p;
>return j + 1;
>}
>
>On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
>NetBSD/alpha (same compiler, really), this produces:
>
>x.c: In function `func':
>x.c:4: warning: cast from pointer to integer of different size
>
>It'd be *really* nice if we could add a flag where such errors could be
>checked for and emitted for an i386 build.

David would know for certain, but I think this is messy to detect.  As
I see it, the problem is that when casting a pointer type to an
integer type, gcc only looks at the lengths of the types - on an i386,
sizeof(int) == sizeof(long) == sizeof(void *), whereas on an Alpha,
sizeof(int) != sizeof(long) == sizeof(void *).  Whilst it is possible
to change the check so that it verifies that the integer type is
`long' (or longer), this may cause other problems.

A further obstacle is that [u]intptr_t  maps to an [u]int on the i386
and I don't think that gcc can tell the difference between (int) and
(intptr_t) when applied to a pointer.

One solution would be to make [u]intptr_t a `magic' type in gcc and
have it whinge whenever a pointer or [u]intptr_t was cast or assigned
to anything other than a pointer or [u]intptr_t.  This is probably a
non-trivial task in gcc and would lead to lots of false positives.

Overall, I think that making developers more aware of cross-platform
issues, combined with the availability of test boxes (like beast) is
a better solution.  It's definitely unreasonable to expect all
developers to own machines for all the target architectures.

Another random thought:  If it was easier to build/install a
cross-platform version of gcc, it might be easier to convince
developers to at least check that compiling on different platforms
works before committing.

Peter

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[GH]

> Actually, the growing realization (at least to me) that the problem
> probably cannot be solved except via software tools, unless the FreeBSD
> community gets more like the NetBSD community in terms of awareness-
> which can only happen if it happens.
> 
> I don't know how you feel about it, but I believe that this *is*
> productive. We can then spend a lot less time with unmet expectations,
> once the expecations are more realistically set, yes?

Absolutely, I agree entirely that Something Is Wrong and that the FreeBSD
development community would benefit from some modifications to policy
and more importantly to attitude

The general realization is most productive, but you have to go around all
the bickering.

Nothing really.

We now return to regularly scheduled programming.

gh

> -matt

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Fri, 6 Jul 2001, Peter Jeremy wrote:

> On 2001-Jul-05 20:31:43 -0700, Matthew Jacob <[EMAIL PROTECTED]> wrote:
> >Perhaps what we really need- and this is really a toolchain issues- is a
> >compiler that is just as stringent on i386 as on alpha?
> 
> IMHO, the compiler _is_ just as stringent on i386 as Alpha (it's the
> same compiler).

True. I didn't quite put it correctly. It's true that the compilers are
the same- but they do have different code generators, and they really do
have different levels of acceptance for errors that don't seem to be
type related.


>  IMHO, the problem splits into two categories:
> Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
> and the i386. 

Yes.  This tends to be caught by the alpha compiler but the i386.
It'd be nice if there were a -Wpun. For example:

x.c:

int
func(char *p)
{
int j = (int) p;
return j + 1;
}

On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
NetBSD/alpha (same compiler, really), this produces:

x.c: In function `func':
x.c:4: warning: cast from pointer to integer of different size

It'd be *really* nice if we could add a flag where such errors could be
checked for and emitted for an i386 build.



> Secondly, there are cases where different architectures
> map foo_t onto different primitive types.  Both these problems are
> very difficult to solve using a lint-like tool running on only one
> architecture.
> 
> As examples of the latter, a quick diff of
> /sys/{i386,alpha}/include/{ansi,types}.h reveals the following:
> i386 type Alpha type
> clock_t   unsigned long   int

Both should be u_int32_t until we decide Unix will last past 2038(?) in
which case they'll both be uint64...

> ptrdiff_t int long
> size_tunsigned intunsigned long
> ssize_t   int long
> off_t __int64_t   long
> *physaddr { int r[1]; }   { long r[1]; }
> label_t   { int [6]; }{ long [10]; }
> vm_offset_t   unsigned intunsigned long
> vm_ooffset_t  __int64_t   long
> vm_pindex_t   unsigned intunsigned long
> vm_size_t unsigned intunsigned long
> register_t__int32_t   __int64_t
> u_register_t  __uint32_t  __uint64_t
> intfptr_t int long
> uintfptr_tunsigned intunsigned long

I'm a little out of my depth about the right thing here- my
heavy toolchain experience is >= 10 years ago. I wish Bruce and/or David
could help sort this out.

-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Peter Jeremy]

On 2001-Jul-05 20:31:43 -0700, Matthew Jacob <[EMAIL PROTECTED]> wrote:
>Perhaps what we really need- and this is really a toolchain issues- is a
>compiler that is just as stringent on i386 as on alpha?

IMHO, the compiler _is_ just as stringent on i386 as Alpha (it's the
same compiler).  IMHO, the problem splits into two categories:
Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
and the i386.  Secondly, there are cases where different architectures
map foo_t onto different primitive types.  Both these problems are
very difficult to solve using a lint-like tool running on only one
architecture.

As examples of the latter, a quick diff of
/sys/{i386,alpha}/include/{ansi,types}.h reveals the following:
  i386 type Alpha type
clock_t unsigned long   int
ptrdiff_t   int long
size_t  unsigned intunsigned long
ssize_t int long
off_t   __int64_t   long
*physaddr   { int r[1]; }   { long r[1]; }
label_t { int [6]; }{ long [10]; }
vm_offset_t unsigned intunsigned long
vm_ooffset_t__int64_t   long
vm_pindex_t unsigned intunsigned long
vm_size_t   unsigned intunsigned long
register_t  __int32_t   __int64_t
u_register_t__uint32_t  __uint64_t
intfptr_t   int long
uintfptr_t  unsigned intunsigned long

Peter

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Thu, 5 Jul 2001, GH wrote:

> > > I have to laugh. Sorry if you don't that helps. S'long then. I've no
> > > more time for the likes of you.
> > 
> > *rolls eyes*  Man, some people are hard to work in a team with.
> 
> You guys are still trying to pass this off as a team??
> *boggle*
> 
> gh
> 
> (Yeah yeah, unproductive..but what part of this thread /has/ been?)

Actually, the growing realization (at least to me) that the problem
probably cannot be solved except via software tools, unless the FreeBSD
community gets more like the NetBSD community in terms of awareness-
which can only happen if it happens.

I don't know how you feel about it, but I believe that this *is*
productive. We can then spend a lot less time with unmet expectations,
once the expecations are more realistically set, yes?


-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[GH]

> > I have to laugh. Sorry if you don't that helps. S'long then. I've no
> > more time for the likes of you.
> 
> *rolls eyes*  Man, some people are hard to work in a team with.

You guys are still trying to pass this off as a team??
*boggle*

gh

(Yeah yeah, unproductive..but what part of this thread /has/ been?)

> Kris



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Thu, 5 Jul 2001, Kris Kennaway wrote:

> On Thu, Jul 05, 2001 at 09:41:21PM -0700, Matthew Jacob wrote:
> 
> > Did you read my other mails? I doesn't appear that you have. Or you
> > didn't understand them. I was laughing because, yes, WARNS was turned on
> > prematurely which killed things.
> 
> Well, your email didn't translate well, because it came across to me
> as if you were scoffing at the suggestion but without explaining your
> actual reasons for laughing.  If that wasn't your intention, then
> okay.

Nope, not in the slightest.

> 
> > I have to laugh. Sorry if you don't that helps. S'long then. I've no
> > more time for the likes of you.
> 
> *rolls eyes*  Man, some people are hard to work in a team with.

I work fine in teams of peers. Whups! Just pulling your leg. Can't take
a joke, can you? Oh, well, such is life.



-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 09:41:21PM -0700, Matthew Jacob wrote:

> Did you read my other mails? I doesn't appear that you have. Or you
> didn't understand them. I was laughing because, yes, WARNS was turned on
> prematurely which killed things.

Well, your email didn't translate well, because it came across to me
as if you were scoffing at the suggestion but without explaining your
actual reasons for laughing.  If that wasn't your intention, then
okay.

> I have to laugh. Sorry if you don't that helps. S'long then. I've no
> more time for the likes of you.

*rolls eyes*  Man, some people are hard to work in a team with.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Thu, 5 Jul 2001, Kris Kennaway wrote:

> On Thu, Jul 05, 2001 at 08:07:40PM -0700, Matthew Jacob wrote:
> > 
> > 
> > On Thu, 5 Jul 2001, Kris Kennaway wrote:
> > 
> > > On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
> > > > Since David's busy, I'm working on it now.  Just some build issues to
> > > > be worked out since warnings were made fatal recently.
> > > 
> > > What problems?  There shouldn't be any fatalities from warnings unless
> > > people have marked something with WARNS prematurely.
> > 
> > ROTFLH
> 
> *sigh* Matt, this isn't helping: if you have something meaningful to
> say here, then please say it.  In case it's slipped you by, people are
> concerned about improving the quality of code on the Alpha -- I don't
> own one and probably never will, but I (and a number of other "i386
> people") have been trying to do our bit to improve portability by
> fixing warnings and cast mismatches.
> 
> Or I could go back and do other things and leave you Alpha people
> alone to bitch and complain amongst yourselves about how no-one cares
> about the FreeBSD/Alpha port.
> 
> Maybe we're going about it the wrong way -- this is the discussion
> we're trying to have in this thread.  Your attention and comments
> would be appreciated, if you care to give them.

Did you read my other mails? I doesn't appear that you have. Or you
didn't understand them. I was laughing because, yes, WARNS was turned on
prematurely which killed things.

I have to laugh. Sorry if you don't that helps. S'long then. I've no
more time for the likes of you.


-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 08:07:40PM -0700, Matthew Jacob wrote:
> 
> 
> On Thu, 5 Jul 2001, Kris Kennaway wrote:
> 
> > On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
> > > Since David's busy, I'm working on it now.  Just some build issues to
> > > be worked out since warnings were made fatal recently.
> > 
> > What problems?  There shouldn't be any fatalities from warnings unless
> > people have marked something with WARNS prematurely.
> 
> ROTFLH

*sigh* Matt, this isn't helping: if you have something meaningful to
say here, then please say it.  In case it's slipped you by, people are
concerned about improving the quality of code on the Alpha -- I don't
own one and probably never will, but I (and a number of other "i386
people") have been trying to do our bit to improve portability by
fixing warnings and cast mismatches.

Or I could go back and do other things and leave you Alpha people
alone to bitch and complain amongst yourselves about how no-one cares
about the FreeBSD/Alpha port.

Maybe we're going about it the wrong way -- this is the discussion
we're trying to have in this thread.  Your attention and comments
would be appreciated, if you care to give them.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[Matthew Jacob]

Perhaps what we really need- and this is really a toolchain issues- is a
compiler that is just as stringent on i386 as on alpha?

I dunno- there used to be a flag to lint that would worn about
non-portable size casts. Is there a gcc flag that would cover most
of the heavy lifting for this on i386?

I'm really well aware that people don't always have the time to test
compile each micro change. I'm also heavily aware that groups like
NetBSD have a mindset that makes them avoid such problems to begin with.
Few (yes, no insult intended, but, yes, "Few") developers in FreeBSD
really understand this except maybe at a vague intellectual level. I'm
not sure how we can get there. Insults don't work- even though I
certainly fire off too many salvos of them myself and am hardly in a
position to be sanctimonious on this topic.

This is a very complicated subject. It isn't just a cross-architectural
issue. It's also a multi-timezone, no real design review, fix it quickly
ex-poste type of problem. The same stuff happens *within* an
architecture.

Many companies have solved this type of problem by requiring proof of
complete builds (and cstyle too) prior to committal (Sun) to a parent
tree. I don't see that happening here.

Nightly builds help. Legato and Auspex and other places I've worked-
instituting a nightly build with email to everyone helps keep people at
least *aware* of the breakage. But this is not quite pragmatic for a
multi-timezone devloper base as we have because, like a WAN, the tree
should probably be assumed to always be in transition.

So- I'm not sure if institutional process really helps us here. Hence,
we probably need some beefier tool support. Maybe we really should get
serious about at least kernel LINT again.

And this, btw, is just to check the syntax. The *semantics* of what we
change is quite different. I fixed Matt Dillon's vm_zoneidle boo-boo in
15 minutes (12 of which waiting for a response on the breakage). It took
about 2 hours this morning of boot/crash/fix/boot/crash/fix to actually
sort out the semantics.

I would suggest that at least the following might be helpful:

a) Send changes to audit@ if they're major.

b) *try* at least to compile on more than one arch - ask someone for
help if you don't have access. Note that Bosko's changes were
checked by me for alpha- that was a good way for this to work.
Note that Matt's VM changes were checked by me, after things
didn't work (or compile) any more. That's not such a good way
for these things to happen.

When things are a broken- and not just s cvsup timing issue, I intend to
try and do the following:

Send mail to -current stating apparent breakage

State whether I intend to try and fix it myself or not

If the responsible party for the breakage is known, they will be
directly addressed also.

I'll try not to be irritated. I just want the problem to go away. If the
timing of the breakage is such that I'll miss my only window for working
on Freebsd-Alpha for several days (as has happened about 7 times in the
last year), so be it.

The same issue will arrive for ia64 and sparc64, too.

-matt



On Thu, 5 Jul 2001, David O'Brien wrote:

> On Thu, Jul 05, 2001 at 02:17:51PM -0700, Matthew Jacob wrote:
> > David claimed he would upgrade beast at some point- but he's pretty
> > busy.
> 
> Acutally out of the state on a WRS forced "vacation". :-(
>  
> > 1. If I had the authority to do so, I'd drive over to Concord and do it.
> > I can do that next week some time.
> 
> beast is actually now in an Exodus facility.
> 
> Not that updating Beast would be the most productive thing considering
> how totally unusable 5-CURRENT is on Alpha right now.
> 
> > > Actually, you can work around this if you set enough environment
> > > variables, but it certainly is annoying to do.
> 
> What is so hard with ``make -m /home/kris/mk''?
> In fact I would say that *no one* should be doing "warnings" cleanup with
> testing on the Alpha or sparc64 -- the i386 lets people change sloppy
> code to be even more sloppy and get away with it.
> 
> -- 
> -- David([EMAIL PROTECTED])
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Thu, 5 Jul 2001, Kris Kennaway wrote:

> On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
> > Since David's busy, I'm working on it now.  Just some build issues to
> > be worked out since warnings were made fatal recently.
> 
> What problems?  There shouldn't be any fatalities from warnings unless
> people have marked something with WARNS prematurely.

ROTFLH



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

Yes, I've actually been massaging a few of those- glad somebody's on
it. I'll come on out to Concord if you you need a hand It's
sometimes hard to keep -current up on an alpha long enough for a
complete buildworld


On Thu, 5 Jul 2001, Jordan Hubbard wrote:

> Since David's busy, I'm working on it now.  Just some build issues to
> be worked out since warnings were made fatal recently.
> 
> - Jordan
> 
> From: Matthew Jacob <[EMAIL PROTECTED]>
> Subject: Re: chgrp broken on alpha systems
> Date: Thu, 5 Jul 2001 14:17:51 -0700 (PDT)
> 
> > 
> > David claimed he would upgrade beast at some point- but he's pretty
> > busy.
> > 
> > 1. If I had the authority to do so, I'd drive over to Concord and do it.
> > I can do that next week some time.
> > 
> > 2. If I had > 144KBit DSL, I'd pay the extra power bills and leave up a
> > PC164 at Feral all the time for people to do this.
> > 
> > 3. If I had the ability to sweet talk the NASA/Ames folks, I'd leave a
> > machine there up all the time.
> > 
> > If beast can't be upgraded soon, and #1 can't happen, I will make #2
> > happen. I have two PC164s- and one could just be left up all the time.
> > 
> > On Thu, 5 Jul 2001, Kris Kennaway wrote:
> > 
> > > On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote:
> > > > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > > > it's just the same old same old refrain of "beast is broken" or
> > > > > "oh well", etc. etc. etc but yer right, insulting does no
> > > > > good.
> > > > >
> > > > > I beg too much hard cider at dinner. It makes the veins in the forehead
> > > > > swell and makes one impatient.
> > > >
> > > > I have no problem with that :)  And beast isn't broken, it's just that
> > > > its bsd.*.mk files are too old to test WARNS patches.
> > >
> > > Actually, you can work around this if you set enough environment
> > > variables, but it certainly is annoying to do.
> > >
> > > Kris
> > >
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 05:49:56PM -0700, David O'Brien wrote:
> On Wed, Jul 04, 2001 at 12:12:22AM -0700, Kris Kennaway wrote:
> > This kind of language isn't called for.  People make mistakes, and
> > insulting them for it serves no useful purpose.
> 
> People are making more and more mistakes that break the Alpha build.
> We will soon have two more arches.  We need to get better in our
> practices

I addressed this part in another message.

> -- so what do you suggest if you don't like our form of peer
> pressure?

The issue you quoted me on above has already been resolved, but I'll
still point out that peer pressure is not the same as trading of
vicious insults.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 05:38:31PM -0700, David O'Brien wrote:

> What is so hard with ``make -m /home/kris/mk''?

That's actually not one of the hoops you need to jump through on beast
-- I think I got someone to install the new mk files already.  The
main hoops are related to stale /usr/include and so forth.

> In fact I would say that *no one* should be doing "warnings" cleanup with
   
without?

> testing on the Alpha or sparc64 -- the i386 lets people change sloppy
> code to be even more sloppy and get away with it.

Kris
 PGP signature

Re: chgrp broken on alpha systems

[John Baldwin]

On 06-Jul-01 Dima Dorfman wrote:
>> In the WARNS= case, another
>> workable method would be to commit the warning fixes but don't commit the
>> actual WARNS= change until the build has been verified on all archs.
> 
> This doesn't work.  The point of WARNS, as I see it anyway, is not to
> scrub the tree so that `make buildworld` produces less warning output.
> The point is that people who are modifying programs are less likely to
> introduce bugs if warnings as treated as errors (presumably, the
> compile outputs good warnings that actually help find bugs).  The
> above (your idea) works when WARNS= is set the first time, but not
> when a program with WARNS set is modified.  This, I think, is the real
> problem; it isn't a problem to test on all arches when you *first* set
> WARNS.  The problem is somebody making a small change to the program
> later.  They may not even know WARNS is set; their code didn't trigger
> warnings on their test box, so they think it's okay.  Furthermore,
> this makes it harder for non-committers to submit changes; at least
> committers have potential access to the other arches (e.g., beast).

Good point.  However, I would argue that we don't need to just lower the
standard and say its ok for warnings to persist.  These things can be fixed to
work on all archs.  One thing that would help is for people to be a little less
uptight and when a bogon pops up on one arch just fix it and go on.  Yelling
and screeching about it doesn't really accomplish anything, and people who are
more familiar with the arch are in a much better position to fix the little
bogon's (size_t instead of int) anyways.

Basically, some people take offense every time the alpha build breaks and spend
more time complaining about it then it would take to just commit the simple fix.
Recently, this trend has started changing somewhat (Matt does commit lots of
quick fixes for simple build breakages nowadays) and I think that just
realising that developers have limited time to spend on this project
(volunteers after all) and being a little more flexible is probably the most
practical solution.  It is current after all.  By the time changes get MFC'd,
they will have surived all the archs and won't break stable.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 06:54:45PM -0700, Dima Dorfman wrote:

> > Matt Jacob usually steps in and fixes breakages on the alpha.  At the minimum,
> > people should be either testing the build on all archs, or asking for someone
> > else to review the patch on archs they don't have available (this last is a
> > more feasible means as we add more and more archs, we can't expect everyone to
> > own a x86, sparc64, ppc, alpha, and ia64).
> 
> No, but I think it's reasonable to expect that we can get some
> test/build boxes for these arches like we have beast for the Alpha.
> 
> I'm curious how NetBSD does this.  We got the WARNS stuff from them,
> and they have a lot more arches than we plan on in the foreseeable
> future.  Kris?

I don't know how NetBSD deal with it.

> I guess what I'm saying is that we might want to rethink how we use
> WARNS.  It'd be nice if the tree would compile warning-free on all
> arches imaginable, but this simply isn't going to happen.  Perhaps it
> makes sense to set NO_WERROR by default in a buildworld so that
> causing a warning on some arch isn't considered as bad as breaking
> world (this is less important on -current than it is on -stable).
> Kris already said that NO_WERROR would be the default in -stable, but
> it may even makes sense in -current; those developers that have a few
> spare minutes can unset it when they build world, and fix the warnings
> (or errors, now) as they encounter them.  This has the advantage of
> making less people angry, and keeping the benifit of WARNS (i.e.,
> finding bugs before they turn into a multitude of PRs).

My thought has always been that if it becomes too troublesome to
prevent people introducing fatal warnings on some architectures, we
can enable NO_WERROR for that arch.  This will also probably be needed
during the porting phase to new architectures which may produce
different kinds of gcc warnings.

I guess it's up to the alpha developers to decide if the rate of
warnings being introduced is annoying enough to warrant NO_WERROR on
their platform, or if it's better to just fix the (usually trivial)
warnings as they come up, so the code stays clean and portable and
doesn't get left behind.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 06:00:25PM -0700, John Baldwin wrote:
> 
> On 05-Jul-01 Kris Kennaway wrote:
> > On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
> >> Since David's busy, I'm working on it now.  Just some build issues to
> >> be worked out since warnings were made fatal recently.
> > 
> > What problems?  There shouldn't be any fatalities from warnings unless
> > people have marked something with WARNS prematurely.
> 
> Err, that's exactly the problem.  People have turned on WARNS= after only
> testing on i386 and thus breaking the alpha when alpha-specific (or
> P64-specific) warnings turn up.

There have been one or two instances of that, but they've all been
quickly corrected, and in fact it sounds like Jordan's was one of
those.  It sounded like he was talking about further, continuing
problems beyond this.

Yes, people need to be more careful when enabling WARNS and not do it
until they've positively tested it on alpha.

Kris
 PGP signature

Re: chgrp broken on alpha systems

[Dima Dorfman]

John Baldwin <[EMAIL PROTECTED]> writes:
> 
> On 06-Jul-01 Jordan Hubbard wrote:
> > Well, unless implicit pointer-to-int conversions have suddenly become
> > fatal, it blew up on something that just got fixed (I went to commit
> > the fix and found that someone else had already done so in the last 12
> > hours).  The world build has been restarted and is running again.
> 
> Matt Jacob usually steps in and fixes breakages on the alpha.  At the minimum,
> people should be either testing the build on all archs, or asking for someone
> else to review the patch on archs they don't have available (this last is a
> more feasible means as we add more and more archs, we can't expect everyone to
> own a x86, sparc64, ppc, alpha, and ia64).

No, but I think it's reasonable to expect that we can get some
test/build boxes for these arches like we have beast for the Alpha.

I'm curious how NetBSD does this.  We got the WARNS stuff from them,
and they have a lot more arches than we plan on in the foreseeable
future.  Kris?

> In the WARNS= case, another
> workable method would be to commit the warning fixes but don't commit the
> actual WARNS= change until the build has been verified on all archs.

This doesn't work.  The point of WARNS, as I see it anyway, is not to
scrub the tree so that `make buildworld` produces less warning output.
The point is that people who are modifying programs are less likely to
introduce bugs if warnings as treated as errors (presumably, the
compile outputs good warnings that actually help find bugs).  The
above (your idea) works when WARNS= is set the first time, but not
when a program with WARNS set is modified.  This, I think, is the real
problem; it isn't a problem to test on all arches when you *first* set
WARNS.  The problem is somebody making a small change to the program
later.  They may not even know WARNS is set; their code didn't trigger
warnings on their test box, so they think it's okay.  Furthermore,
this makes it harder for non-committers to submit changes; at least
committers have potential access to the other arches (e.g., beast).

I guess what I'm saying is that we might want to rethink how we use
WARNS.  It'd be nice if the tree would compile warning-free on all
arches imaginable, but this simply isn't going to happen.  Perhaps it
makes sense to set NO_WERROR by default in a buildworld so that
causing a warning on some arch isn't considered as bad as breaking
world (this is less important on -current than it is on -stable).
Kris already said that NO_WERROR would be the default in -stable, but
it may even makes sense in -current; those developers that have a few
spare minutes can unset it when they build world, and fix the warnings
(or errors, now) as they encounter them.  This has the advantage of
making less people angry, and keeping the benifit of WARNS (i.e.,
finding bugs before they turn into a multitude of PRs).

Thoughts?

Dima Dorfman
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[John Baldwin]

On 06-Jul-01 Jordan Hubbard wrote:
> Well, unless implicit pointer-to-int conversions have suddenly become
> fatal, it blew up on something that just got fixed (I went to commit
> the fix and found that someone else had already done so in the last 12
> hours).  The world build has been restarted and is running again.

Matt Jacob usually steps in and fixes breakages on the alpha.  At the minimum,
people should be either testing the build on all archs, or asking for someone
else to review the patch on archs they don't have available (this last is a
more feasible means as we add more and more archs, we can't expect everyone to
own a x86, sparc64, ppc, alpha, and ia64).  In the WARNS= case, another
workable method would be to commit the warning fixes but don't commit the
actual WARNS= change until the build has been verified on all archs.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[John Baldwin]

On 05-Jul-01 Kris Kennaway wrote:
> On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
>> Since David's busy, I'm working on it now.  Just some build issues to
>> be worked out since warnings were made fatal recently.
> 
> What problems?  There shouldn't be any fatalities from warnings unless
> people have marked something with WARNS prematurely.

Err, that's exactly the problem.  People have turned on WARNS= after only
testing on i386 and thus breaking the alpha when alpha-specific (or
P64-specific) warnings turn up.

> Kris

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Jordan Hubbard]

Well, unless implicit pointer-to-int conversions have suddenly become
fatal, it blew up on something that just got fixed (I went to commit
the fix and found that someone else had already done so in the last 12
hours).  The world build has been restarted and is running again.

- Jordan

From: Kris Kennaway <[EMAIL PROTECTED]>
Subject: Re: chgrp broken on alpha systems
Date: Thu, 5 Jul 2001 16:22:27 -0700

> On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
> > Since David's busy, I'm working on it now.  Just some build issues to
> > be worked out since warnings were made fatal recently.
> 
> What problems?  There shouldn't be any fatalities from warnings unless
> people have marked something with WARNS prematurely.
> 
> Kris

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Wed, Jul 04, 2001 at 12:12:22AM -0700, Kris Kennaway wrote:
> This kind of language isn't called for.  People make mistakes, and
> insulting them for it serves no useful purpose.

People are making more and more mistakes that break the Alpha build.
We will soon have two more arches.  We need to get better in our
practices -- so what do you suggest if you don't like our form of peer
pressure?
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Wed, Jul 04, 2001 at 08:53:59AM +0200, Dag-Erling Smorgrav wrote:
> > Not normal, except by dimwits who add WARNS?= 2 w/o checking.
> 
> Now, would it really have been so hard to just send (or even commit) a
> patch that declares len as a size_t rather than an unsigned int,
> instead of calling people names?  I don't have a frickin' Alpha, you
> dimwit, and beast is so out of date it's useless.  Send me a working

1. if you cannot test properly don't do "WARNS" "fixing".
   find something else to work on

2. you have suffient diskspace to check out things into and 
   `make -m /home/des/src/share/mk' is easly enough you should be able to
   handle it

> Alpha with at least 64 MB RAM and 4 GB disk, then we'll talk.
 
Or go buy one with your own money like a lot of us did, so we could test
things w/o fcking them up.

-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[David O'Brien]

On Thu, Jul 05, 2001 at 02:17:51PM -0700, Matthew Jacob wrote:
> David claimed he would upgrade beast at some point- but he's pretty
> busy.

Acutally out of the state on a WRS forced "vacation". :-(
 
> 1. If I had the authority to do so, I'd drive over to Concord and do it.
> I can do that next week some time.

beast is actually now in an Exodus facility.

Not that updating Beast would be the most productive thing considering
how totally unusable 5-CURRENT is on Alpha right now.

> > Actually, you can work around this if you set enough environment
> > variables, but it certainly is annoying to do.

What is so hard with ``make -m /home/kris/mk''?
In fact I would say that *no one* should be doing "warnings" cleanup with
testing on the Alpha or sparc64 -- the i386 lets people change sloppy
code to be even more sloppy and get away with it.

-- 
-- David([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 04:12:22PM -0700, Jordan Hubbard wrote:
> Since David's busy, I'm working on it now.  Just some build issues to
> be worked out since warnings were made fatal recently.

What problems?  There shouldn't be any fatalities from warnings unless
people have marked something with WARNS prematurely.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[Jordan Hubbard]

Since David's busy, I'm working on it now.  Just some build issues to
be worked out since warnings were made fatal recently.

- Jordan

From: Matthew Jacob <[EMAIL PROTECTED]>
Subject: Re: chgrp broken on alpha systems
Date: Thu, 5 Jul 2001 14:17:51 -0700 (PDT)

> 
> David claimed he would upgrade beast at some point- but he's pretty
> busy.
> 
> 1. If I had the authority to do so, I'd drive over to Concord and do it.
> I can do that next week some time.
> 
> 2. If I had > 144KBit DSL, I'd pay the extra power bills and leave up a
> PC164 at Feral all the time for people to do this.
> 
> 3. If I had the ability to sweet talk the NASA/Ames folks, I'd leave a
> machine there up all the time.
> 
> If beast can't be upgraded soon, and #1 can't happen, I will make #2
> happen. I have two PC164s- and one could just be left up all the time.
> 
> On Thu, 5 Jul 2001, Kris Kennaway wrote:
> 
> > On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote:
> > > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > > it's just the same old same old refrain of "beast is broken" or
> > > > "oh well", etc. etc. etc but yer right, insulting does no
> > > > good.
> > > >
> > > > I beg too much hard cider at dinner. It makes the veins in the forehead
> > > > swell and makes one impatient.
> > >
> > > I have no problem with that :)  And beast isn't broken, it's just that
> > > its bsd.*.mk files are too old to test WARNS patches.
> >
> > Actually, you can work around this if you set enough environment
> > variables, but it certainly is annoying to do.
> >
> > Kris
> >
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

David claimed he would upgrade beast at some point- but he's pretty
busy.

1. If I had the authority to do so, I'd drive over to Concord and do it.
I can do that next week some time.

2. If I had > 144KBit DSL, I'd pay the extra power bills and leave up a
PC164 at Feral all the time for people to do this.

3. If I had the ability to sweet talk the NASA/Ames folks, I'd leave a
machine there up all the time.

If beast can't be upgraded soon, and #1 can't happen, I will make #2
happen. I have two PC164s- and one could just be left up all the time.

On Thu, 5 Jul 2001, Kris Kennaway wrote:

> On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote:
> > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > it's just the same old same old refrain of "beast is broken" or
> > > "oh well", etc. etc. etc but yer right, insulting does no
> > > good.
> > >
> > > I beg too much hard cider at dinner. It makes the veins in the forehead
> > > swell and makes one impatient.
> >
> > I have no problem with that :)  And beast isn't broken, it's just that
> > its bsd.*.mk files are too old to test WARNS patches.
>
> Actually, you can work around this if you set enough environment
> variables, but it certainly is annoying to do.
>
> Kris
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Thu, Jul 05, 2001 at 11:00:09AM +0200, Dag-Erling Smorgrav wrote:
> Matthew Jacob <[EMAIL PROTECTED]> writes:
> > it's just the same old same old refrain of "beast is broken" or
> > "oh well", etc. etc. etc but yer right, insulting does no
> > good.
> > 
> > I beg too much hard cider at dinner. It makes the veins in the forehead
> > swell and makes one impatient.
> 
> I have no problem with that :)  And beast isn't broken, it's just that
> its bsd.*.mk files are too old to test WARNS patches.

Actually, you can work around this if you set enough environment
variables, but it certainly is annoying to do.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[GH]

On Wed, Jul 04, 2001 at 09:54:50AM +0200, some SMTP stream spewed forth: 
> Gentlemen,
> 
> Please? I will happily supply you with ample quantities of quality
> Dutch mud to sling at one another. But please do so in private?

But think of the money we'll save on wrestling tickets.

gh

> 
> tnx
> Wilko
> 
> > Matthew Jacob <[EMAIL PROTECTED]> writes:
> >> There is, in my mailbox, a grotesque and unforgiveable insult from you
> >> from some months back.  You deserve no respect whatsoever.
> > 
> > Heh.  You're so cute.
> > 
> > DES
> > -- 
> > Dag-Erling Smorgrav - [EMAIL PROTECTED]
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> 
> 
> -- 
> |   / o / /  _   Arnhem, The Netherlandsemail: 
> [EMAIL PROTECTED]
> |/|/ / / /( (_) Bulte   
> http://www.FreeBSD.org
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Wilko Bulte]

Gentlemen,

Please? I will happily supply you with ample quantities of quality
Dutch mud to sling at one another. But please do so in private?

tnx
Wilko

> Matthew Jacob <[EMAIL PROTECTED]> writes:
>> There is, in my mailbox, a grotesque and unforgiveable insult from you
>> from some months back.  You deserve no respect whatsoever.
> 
> Heh.  You're so cute.
> 
> DES
> -- 
> Dag-Erling Smorgrav - [EMAIL PROTECTED]
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


-- 
|   / o / /  _   Arnhem, The Netherlandsemail: 
[EMAIL PROTECTED]
|/|/ / / /( (_) Bulte   
http://www.FreeBSD.org




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

> > > There is no -Wall or -Werror in normal /usr/src builds. Try again.
> > 
> > Sorry- let me modify that.
> > 
> > Not normal, except by dimwits who add WARNS?= 2 w/o checking.
> 
> This kind of language isn't called for.  People make mistakes, and
> insulting them for it serves no useful purpose.

yah, yah, yah, yah, yah.

it's just the same old same old refrain of "beast is broken" or
"oh well", etc. etc. etc but yer right, insulting does no
good.

I beg too much hard cider at dinner. It makes the veins in the forehead
swell and makes one impatient.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Tue, Jul 03, 2001 at 09:34:10PM -0700, Matthew Jacob wrote:
> 
> S> > > are on for  is the kernel- and even that isn't -Werror.
> > > 
> > > You're about two months out of date; we started locking down userland
> > 
> > > code around that timeframe.  This one probably wasn't tested
> > > thoroughly enough on alpha.
> > 
> > Too much frickin' ergot in yer wheaties, bucko.
> > 
> > There is no -Wall or -Werror in normal /usr/src builds. Try again.
> 
> Sorry- let me modify that.
> 
> Not normal, except by dimwits who add WARNS?= 2 w/o checking.

This kind of language isn't called for.  People make mistakes, and
insulting them for it serves no useful purpose.

Kris
 PGP signature

Re: chgrp broken on alpha systems

[Matthew Jacob]

On 4 Jul 2001, Dag-Erling Smorgrav wrote:

> Matthew Jacob <[EMAIL PROTECTED]> writes:
> > There is, in my mailbox, a grotesque and unforgiveable insult from you
> > from some months back.  You deserve no respect whatsoever.
> 
> Heh.  You're so cute.

*smooch* to you too, sweetie!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

Oh- btw- let's change the tenor of this slightly:

I apologize to Dag-Erling for calling him a dimwit. 


On Tue, 3 Jul 2001, Matthew Jacob wrote:

> 
> 
> On 4 Jul 2001, Dag-Erling Smorgrav wrote:
> 
> > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > > Too much frickin' ergot in yer wheaties, bucko.
> > > > 
> > > > There is no -Wall or -Werror in normal /usr/src builds. Try again.
> > > 
> > > Sorry- let me modify that.
> > > 
> > > Not normal, except by dimwits who add WARNS?= 2 w/o checking.
> > 
> > Now, would it really have been so hard to just send (or even commit) a
> > patch that declares len as a size_t rather than an unsigned int,
> 
> I made the change.
> 
> > instead of calling people names?
> 
> There is, in my mailbox, a grotesque and unforgiveable insult from you
> from some months back.  You deserve no respect whatsoever.
> 
> >  I don't have a frickin' Alpha, you
> > dimwit, and beast is so out of date it's useless.  Send me a working
> > Alpha with at least 64 MB RAM and 4 GB disk, then we'll talk.
> 
> Talk? Not if I can help it.
> 
> -matt
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Dag-Erling Smorgrav]

Matthew Jacob <[EMAIL PROTECTED]> writes:
> There is, in my mailbox, a grotesque and unforgiveable insult from you
> from some months back.  You deserve no respect whatsoever.

Heh.  You're so cute.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On 4 Jul 2001, Dag-Erling Smorgrav wrote:

> Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > Too much frickin' ergot in yer wheaties, bucko.
> > > 
> > > There is no -Wall or -Werror in normal /usr/src builds. Try again.
> > 
> > Sorry- let me modify that.
> > 
> > Not normal, except by dimwits who add WARNS?= 2 w/o checking.
> 
> Now, would it really have been so hard to just send (or even commit) a
> patch that declares len as a size_t rather than an unsigned int,

I made the change.

> instead of calling people names?

There is, in my mailbox, a grotesque and unforgiveable insult from you
from some months back.  You deserve no respect whatsoever.

>  I don't have a frickin' Alpha, you
> dimwit, and beast is so out of date it's useless.  Send me a working
> Alpha with at least 64 MB RAM and 4 GB disk, then we'll talk.

Talk? Not if I can help it.

-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

S> > > are on for  is the kernel- and even that isn't -Werror.
> > 
> > You're about two months out of date; we started locking down userland
> 
> > code around that timeframe.  This one probably wasn't tested
> > thoroughly enough on alpha.
> 
> Too much frickin' ergot in yer wheaties, bucko.
> 
> There is no -Wall or -Werror in normal /usr/src builds. Try again.

Sorry- let me modify that.

Not normal, except by dimwits who add WARNS?= 2 w/o checking.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Matthew Jacob]

On Tue, 3 Jul 2001, Kris Kennaway wrote:

> On Tue, Jul 03, 2001 at 02:41:33PM -0700, Matthew Jacob wrote:
> > 
> > Hmm. Somebody must have cranked some C compilation up enough to turn
> > warnings into errors.
> > 
> > If I check out chkgrp into /tmp now on a system that's currently trying
> > to update itself, I get:
> > 
> > yorp.feral.com > make
> > Warning: Object directory not changed from original
> > /tmp/src/usr.sbin/chkgrp
> > cc -O -pipe -mcpu=ev4   -c chkgrp.c
> > chkgrp.c: In function `main':
> > chkgrp.c:76: warning: passing arg 2 of `fgetln' from incompatible
> > pointer type
> > cc -O -pipe -mcpu=ev4-o chkgrp chkgrp.o
> > gzip -cn chkgrp.8 > chkgrp.8.gz
> > 
> > 
> > Gee, I wonder who's turned this on for userland? The only thing these
> > are on for  is the kernel- and even that isn't -Werror.
> 
> You're about two months out of date; we started locking down userland

> code around that timeframe.  This one probably wasn't tested
> thoroughly enough on alpha.

Too much frickin' ergot in yer wheaties, bucko.

There is no -Wall or -Werror in normal /usr/src builds. Try again.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: chgrp broken on alpha systems

[Kris Kennaway]

On Tue, Jul 03, 2001 at 02:41:33PM -0700, Matthew Jacob wrote:
> 
> Hmm. Somebody must have cranked some C compilation up enough to turn
> warnings into errors.
> 
> If I check out chkgrp into /tmp now on a system that's currently trying
> to update itself, I get:
> 
> yorp.feral.com > make
> Warning: Object directory not changed from original
> /tmp/src/usr.sbin/chkgrp
> cc -O -pipe -mcpu=ev4   -c chkgrp.c
> chkgrp.c: In function `main':
> chkgrp.c:76: warning: passing arg 2 of `fgetln' from incompatible
> pointer type
> cc -O -pipe -mcpu=ev4-o chkgrp chkgrp.o
> gzip -cn chkgrp.8 > chkgrp.8.gz
> 
> 
> Gee, I wonder who's turned this on for userland? The only thing these
> are on for  is the kernel- and even that isn't -Werror.

You're about two months out of date; we started locking down userland
code around that timeframe.  This one probably wasn't tested
thoroughly enough on alpha.

Kris

 PGP signature

Re: chgrp broken on alpha systems

[Matthew Jacob]

Hmm. Somebody must have cranked some C compilation up enough to turn
warnings into errors.

If I check out chkgrp into /tmp now on a system that's currently trying
to update itself, I get:

yorp.feral.com > make
Warning: Object directory not changed from original
/tmp/src/usr.sbin/chkgrp
cc -O -pipe -mcpu=ev4   -c chkgrp.c
chkgrp.c: In function `main':
chkgrp.c:76: warning: passing arg 2 of `fgetln' from incompatible
pointer type
cc -O -pipe -mcpu=ev4-o chkgrp chkgrp.o
gzip -cn chkgrp.8 > chkgrp.8.gz


Gee, I wonder who's turned this on for userland? The only thing these
are on for  is the kernel- and even that isn't -Werror.



On Tue, 3 Jul 2001, Jim Pirzyk wrote:

> The current version go chkgrp does not compile under alpha systems
>
> grep FreeBSD chkgrp.c
>   "$FreeBSD: src/usr.sbin/chkgrp/chkgrp.c,v 1.5 2001/06/24 12:38:28 des Exp
> $";
>
> ===> usr.sbin/chkgrp
> cc -nostdinc -O -pipe -mcpu=ev4 -mcpu=ev4
> -I/usr/obj/usr/src/alpha/usr/include -W -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type
> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow  -c
> /usr/src/usr.sbin/chkgrp/chkgrp.c
> cc1: warnings being treated as errors
> /usr/src/usr.sbin/chkgrp/chkgrp.c: In function `main':
> /usr/src/usr.sbin/chkgrp/chkgrp.c:76: warning: passing arg 2 of `fgetln' from
> incompatible pointer type
> *** Error code 1
>
> - JimP
>
> --
> --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
> __o   [EMAIL PROTECTED] - [EMAIL PROTECTED]
>  _'\<,_   Senior Systems Engineer, Walt Disney Feature Animation
> (*)/ (*)
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

chgrp broken on alpha systems

[Jim Pirzyk]

The current version go chkgrp does not compile under alpha systems

grep FreeBSD chkgrp.c
  "$FreeBSD: src/usr.sbin/chkgrp/chkgrp.c,v 1.5 2001/06/24 12:38:28 des Exp 
$";

===> usr.sbin/chkgrp
cc -nostdinc -O -pipe -mcpu=ev4 -mcpu=ev4   
-I/usr/obj/usr/src/alpha/usr/include -W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow  -c 
/usr/src/usr.sbin/chkgrp/chkgrp.c
cc1: warnings being treated as errors
/usr/src/usr.sbin/chkgrp/chkgrp.c: In function `main':
/usr/src/usr.sbin/chkgrp/chkgrp.c:76: warning: passing arg 2 of `fgetln' from 
incompatible pointer type
*** Error code 1

- JimP

-- 
--- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
__o   [EMAIL PROTECTED] - [EMAIL PROTECTED]
 _'\<,_   Senior Systems Engineer, Walt Disney Feature Animation 
(*)/ (*)  

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message