unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
marcel> The net effect is that these targets are built in parallel,
marcel> which obviously isn't right.
Agreed. If there is no reason to do "make obj all" (specify both 'obj'
and 'all' target at once), it's maybe a better solution.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [E
On Sun, 12 Nov 2000, Marcel Moolenaar wrote:
> Makoto MATSUSHITA wrote:
> >
> > % make -j 2 modules
> > cd ../../modules && env MAKEOBJDIRPREFIX=/usr/src/sys/compile/GENERIC/modules
>KMODDIR=/boot/kernel make obj all
> > ===> 3dfx
> > ===> 3dfx
> > Warning: Object directory not changed from ori
bde> (In the above example, the targets are built concurrently and race
bde> each other. This is bad when the `all' target wins the race. The
bde> `obj' target runs faster, so it usually wins the race except in the
bde> first directory (3dfx)). More .ORDER statements in *.mk are required.
Tha
On Mon, 13 Nov 2000, Makoto MATSUSHITA wrote:
> bde> (In the above example, the targets are built concurrently and race
> bde> each other. This is bad when the `all' target wins the race. The
> bde> `obj' target runs faster, so it usually wins the race except in the
> bde> first directory (3dfx
During make buildworld:
===> usr.sbin/lpr/lpd
cc -O -pipe -I/usr/src/usr.sbin/lpr/lpd/../common_source -Wall -Wnested-externs
-Wmissing-prototypes -Wno-unused -Wredundant-decls -Wstrict-prototypes -I/usr/
obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/lpr/lpd/lpd.c
/usr/src/usr.sbin/lpr/lpd/
On Mon, 13 Nov 2000 17:24:41 +0100, Andrea Campi wrote:
> I think it wasn't reported yet? No time to debug it, I am at work ;-)
Reported and fixed.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
>
> Though the alpha code (alpha/libalpha/bootinfo.c) also fill in a lot of
> stuff in bi, it has no reference at all to "kernelname". Did it ever
> work? :-)
>
Hmm. Maybe not. I'd convinced myself that the loader is currently just
passing "kernel" either as an environmental variable or in boo
On Sun, Nov 12, 2000 at 11:58:39PM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Makoto MATSUSHITA writes:
> : It does not fix this problem. However, if we separate the execution of
> : "make obj" and "make all", we can avoid (again, not *fix*) the problem.
> : Maybe this change is re
On Mon, Nov 13, 2000 at 07:51:11PM +0900, Makoto MATSUSHITA wrote:
> ! cd $S/modules && env ${MKMODULESENV} ${MAKE} obj all
> --- 310,322
> ! cd $S/modules && env ${MKMODULESENV} ${MAKE} obj
> ! cd $S/modules && env ${MKMODULESENV} ${MAKE} all
I can certainly commit this type of
Bruce Evans wrote:
>
> > Index: Makefile.i386
> > ===
> > RCS file: /home/ncvs/src/sys/conf/Makefile.i386,v
> > retrieving revision 1.212
> > diff -u -r1.212 Makefile.i386
> > --- Makefile.i386 2000/10/29 09:47:50 1.212
> >
David O'Brien wrote:
>
> On Mon, Nov 13, 2000 at 07:51:11PM +0900, Makoto MATSUSHITA wrote:
> > ! cd $S/modules && env ${MKMODULESENV} ${MAKE} obj all
> > --- 310,322
> > ! cd $S/modules && env ${MKMODULESENV} ${MAKE} obj
> > ! cd $S/modules && env ${MKMODULESENV} ${MAKE} all
>
Marcel Moolenaar wrote:
>
> David O'Brien wrote:
> >
> > On Mon, Nov 13, 2000 at 07:51:11PM +0900, Makoto MATSUSHITA wrote:
> > > ! cd $S/modules && env ${MKMODULESENV} ${MAKE} obj all
> > > --- 310,322
> > > ! cd $S/modules && env ${MKMODULESENV} ${MAKE} obj
> > > ! cd $S/module
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: On Sun, Nov 12, 2000 at 11:58:39PM -0700, Warner Losh wrote:
: > In message <[EMAIL PROTECTED]> Makoto MATSUSHITA writes:
: > : It does not fix this problem. However, if we separate the execution of
: > : "make obj" and "make all", we can av
On Mon, Nov 13, 2000 at 01:19:38PM -0500, Marcel Moolenaar wrote:
> I'll commit a fix with just semi-colons today for all architectures if
> someone hasn't done that already by that time.
Can you post a patch first. There seems to be some subtleties here that
might make a review useful.
--
--
It seems that something recently toasted the quasi-magic i8254 timecounter
code to the point of unusability.
On my laptop I run a ntpdate every minute, and the result looks like this:
Nov 13 23:37:00 [...] step time server 212.242.40.181 offset -2.862805 sec
Nov 13 23:38:00 [...] step time serv
Hi,
I'm bewildered and looking for clues ...
I'm running -current, cvsup'd and rebuild world as of yesterday:
FreeBSD stage.bsdhome.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Nov 12 18:30:15 EST
2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
I went to install X from Ports and
On Mon, Nov 13, 2000 at 12:23:08PM -0700, Warner Losh wrote:
> : > I think that make has no business doing an implicit make obj for the
> : > all target.
> : Someone has to run `make obj' for the modules tree. How are you doing it
> : locally?
>
> Right now we do it twice. Once in make dpeend a
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: It doesn't warn the user, it errors out (possibly a suttle distinction
: I'm making). Also in the past a `make depend' for the kernel was not
: required. Just highly suggested. Are we really prepared to make it a
: requirement now?
I am,
David O'Brien wrote:
>
> On Mon, Nov 13, 2000 at 01:19:38PM -0500, Marcel Moolenaar wrote:
> > I'll commit a fix with just semi-colons today for all architectures if
> > someone hasn't done that already by that time.
>
> Can you post a patch first. There seems to be some subtleties here that
>
marcel> No you can't. $S expands to "../.." which only works for the
marcel> first cd in the -jX case. The second cd will fail.
Ouch... give me one more chance to submit a patch. Here's summary:
* src/release/Makefile should use 'module-depend' while
checking dependancy of mod
[-stable removed from the cc list]
Makoto MATSUSHITA wrote:
>
> marcel> No you can't. $S expands to "../.." which only works for the
> marcel> first cd in the -jX case. The second cd will fail.
>
> Ouch...
Sorry :-)
> give me one more chance to submit a patch. Here's summary:
You're not goin
Hi,
I've been working on serial ports/consoles the last few days
and have run into what I consider a bug in getty (-current)..
When the following command is run as root:
/usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1
the call to login_tty() fails in the opentty() function:
I am seeing lots of silo overflows in -current SMP.
#uname -a
FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #2: \
Mon Nov 13 19:31:49 PST 2000 \
root@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386
I this is not related to the recent patch for conversion to mutex. I
tried both ways.
I
Makoto MATSUSHITA wrote:
>
> Ouch... give me one more chance to submit a patch. Here's summary:
I see no reason to not commit Makoto-san's patches with the fix he sent
me for the modules-depend target. The fix is (modulo indentation):
> modules-depend:
> ! cd $S/modules; env ${MKMODULES
In message <[EMAIL PROTECTED]> Marcel Moolenaar writes:
: BTW: I'm also looking at Warner's patch. Maybe that's the better fix for
: it, but I have to dig into the Makefiles a bit more to get a better
: picture...
The implications are that make obj isn't done unless you've run make
depend first.
On Mon, 13 Nov 2000, Thomas D. Dean wrote:
> I am seeing lots of silo overflows in -current SMP.
>
> #uname -a
> FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #2: \
> Mon Nov 13 19:31:49 PST 2000 \
> root@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386
SMPng has many pessimizations that
27 matches
Mail list logo