Hi !
I am starting to be developer on Fbsd and sometime I was working on 5.0,
then I stopped because of lack of time, and after a while I couldn't build
no more, so I decided to reinstall my development environment.
Install went OK, but startup didn't. I know excatly where the problem is. I
a
On Wed, May 29, 2002 at 11:38:57PM -0500, Peter Schultz wrote:
FWIW: same here yesterday. I have not yet investigated what's up
Wilko
> I'm getting the following error on a just built -current, which was a
> fresh install of 5.0-CURRENT-20020519-JPSNAP:
>
> installing in lib/XThrStub...
> rm
I'm getting the following error on a just built -current, which was a
fresh install of 5.0-CURRENT-20020519-JPSNAP:
installing in lib/XThrStub...
rm -f UIThrStubs.o
LD_LIBRARY_PATH=../../exports/lib cc -c -O -pipe-ansi -pedantic
-Dasm=__asm
-Wall -Wpointer-arith -I../.. -I../../exports/
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
When it comes right down to it, I am getting wholely sick and tired
of people acting like rulez-police and complaining about the most
minor, most insignificant syntactical changes imagineable. The
rest of us developers have better things to do with their time then
to spend it
On Wed, 29 May 2002, Peter Wemm wrote:
>
> ie: it is ok to change this:
> if (foo) {
> fumble();
> futz();
> } else
> bah;
>
> into
> } else {
> bah;
> }
In this case it's moot because I already did it as a separate commit
but it was changing:
if (foo) {
mum
On Wed, May 29, 2002 at 10:39:08PM +0200, Sebastien Gioria wrote:
> Hello guys,
>
> I've update May 25 my notebook with a fresh -CURRENT cvsup
> source and now when I want to build a new -current on my notebook
> I've got repeated build failures.
>
> I've got a lot of time this type of error "I
Julian Elischer wrote:
> On Wed, 29 May 2002, Julian Elischer wrote:
> > On Wed, 29 May 2002, John Baldwin wrote:
> > > 4) It would be nice if you didn't mix in gratuitous style changes with
> > >actual content changes such as extra braces in else clause of
> > >PROCFS_CTRL_WAIT case in pr
* From Matthew Dillon <[EMAIL PROTECTED]>
>
> :
> :When you make the code more readable, you introduce further diffs, and you
> :leave no reference against the original code of where the functional changes
> :are. Either make the "base" code cleaned up by committing non-functional
> :changes fir
:
:When you make the code more readable, you introduce further diffs, and you
:leave no reference against the original code of where the functional changes
:are. Either make the "base" code cleaned up by committing non-functional
:changes first, or commit against the "base" code your functional
On Wed, 29 May 2002, Julian Elischer wrote:
>
>
> On Wed, 29 May 2002, John Baldwin wrote:
>
> >
> > 4) It would be nice if you didn't mix in gratuitous style changes with
> >actual content changes such as extra braces in else clause of
> >PROCFS_CTRL_WAIT case in procfs_ctl.c
* From Matthew Dillon <[EMAIL PROTECTED]>
>
> No hold on a minute. Some of us believe that adding those extra
> braces and parenthesis makes the code a whole lot more readable. they
> are NOT gratuitous in the least, certainly not from my point of view!
>
When you make the code mo
In message: <[EMAIL PROTECTED]>
Takanori Watanabe <[EMAIL PROTECTED]> writes:
: 3. Add following line to configuration file. (Should it be standard?)
: ==
: device cardcom
They should be standard. I have a patch that does this for all the
_if* files in the system, with a bloatage of
Ok I just committed that one on it's own
now back to the real points that jhb raised..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:having said that,
:In this case the braces in question in ithread_schedule are:
:- } else
:+ } else {
:curthread->td_kse->ke_flags |= KEF_NEEDRESCHED;
:+ }
:
:I tend to always put braces on the else clause if the 'then' clause
:ha
:
:> Furthermore, it is an extreme and inappropriate imposition on Julian
:> to require that he extract all the alleged 'gratuitous braces and
:> ()'s)' into a separate commit.
:
:Uh, no it isn't. That is the rules we operate under. This type of
:request comes up _daily_, and is gen
On Wed, 29 May 2002, Matthew Dillon wrote:
>
> I agree that as a general rule of thumb it makes sense to commit
> whitespace/paren/brace changes separately, but that is ALL it is.
> A rule of thumb. It should not be followed blindly, on principle,
> if it has an adverse effect
On Wed, 29 May 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Matthew Dillon w
> rites:
>
> >I agree that as a general rule of thumb it makes sense to commit
> >whitespace/paren/brace changes separately, but that is ALL it is.
> >A rule of thumb. It should not be
Hello guys,
I've update May 25 my notebook with a fresh -CURRENT cvsup
source and now when I want to build a new -current on my notebook
I've got repeated build failures.
I've got a lot of time this type of error "Illegal instruction - core dumped"
with or without -j in buildworld in the seco
On Wed, May 29, 2002 at 01:07:01PM -0700, Matthew Dillon wrote:
> :On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
> :> >
> :> > 9) More gratuitous braces as well as gratuituos ()'s and white space
> :> >changes in ithread_schedule() obfuscate the functional diffs.
> :>
> :>
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00A4_81E07D7A.A0001C56"
In message <[EMAIL PROTECTED]>, Matthew Dillon w
rites:
>I agree that as a general rule of thumb it makes sense to commit
>whitespace/paren/brace changes separately, but that is ALL it is.
>A rule of thumb. It should not be followed blindly, on principle,
>if it has an adverse ef
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00B0_33B54E8A.C0266E75"
:On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
:> >
:> > 9) More gratuitous braces as well as gratuituos ()'s and white space
:> >changes in ithread_schedule() obfuscate the functional diffs.
:>
:> I guess so though it made it a hell of a lot more readable to me.
:
:That
Bosko Milekic wrote:
> On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote:
> > Can we get rid of the NULL tests we had to put in when M_WAIT
> > turned into M_WAITOK?
>
> No. What you see as a bad thing others (including me) see as a good
> thing. I _want_ to be able to say: "okay,
On 2002-05-29 00:24 -0700, Peter Wemm wrote:
> There is a known bug in UMA where it recurses and calls itself with with
> M_WAITOK even if it was explicitly called with M_NOWAIT set. The bug is
> real and would cause a panic if we actually ran low on memory at that
> point.
Just in case anyone m
On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
> >
> > 9) More gratuitous braces as well as gratuituos ()'s and white space
> >changes in ithread_schedule() obfuscate the functional diffs.
>
> I guess so though it made it a hell of a lot more readable to me.
That isn't the
On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote:
> configure:3602: checking for XOpenDisplay in -lX11
> configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib
> conftest.C -lX11 1>&5
> /var/tmp//ccask2mP.o: In function `main':
> /usr/ports/editors/openoffice/work/
On Wed, 29 May 2002, John Baldwin wrote:
>
> On 28-May-2002 Julian Elischer wrote:
> > Now things are moving again.
> > Jonathon Mini and I have cleaned up the patches a bit
> > and fixed the more obvious problems..
> > from teh point of view of non KSE processes
> > (that would be all of th
I would like to know as well cause right now I have made it work under
linux using the driver from sourceforge and a patched pppd supporting
PPPoATM and I would say it works pretty stable under 2.4.18. Maybe it
would get to work under Linux emulation but I have never tried so I
would like to know
kthreads are not threads, but, rather, kernel processes..
they have a separate 'proc' structure.
(they are badly named..)
On Wed, 29 May 2002, kai ouyang wrote:
>
> Thank you! I know a little more. From the kthread_create() function, I
> find Both 4.x and 5.0 are implemented by fork1(). I am p
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, John Baldwin writes:
>
> >+ frame = td->td_frame;
> >+ frame->tf_eax = retval; /* Child returns zero */
> >+ frame->tf_edx = aux;/* I dunno */
> >
> >You could always ask about that instead of having
Hi all,
> Have you done a 'make world' in the last 24 hours or so? What does this show:
No. And I have tested it now in STABLE to with the gcc32 and gcc31 ports.
Result is the same.
gcc295 in stable, and a march gcc31 port are fine. All other gcc3.x versions
are failing.
> ls -l /usr/bin/c++
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>+ frame = td->td_frame;
>+ frame->tf_eax = retval; /* Child returns zero */
>+ frame->tf_edx = aux;/* I dunno */
>
>You could always ask about that instead of having a I dunno comment. :)
>I think that we
Martin Blapp wrote:
>
> Hi all,
>
> I see this configure failure when using the system gcc3.1 or a newer one from
> ports. A version from march works.
>
> configure:3602: checking for XOpenDisplay in -lX11
> configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib
> conftest.C
On Wed, 29 May 2002 09:27:50 MST, "Dan Trainor" wrote:
> Being that -CURRENT's C++ compiler is b0rked, how long will it be until
> it's problems have been resolved? I've seen many problems with it
> lately, and it kinda made me worried, almost to the point where I
> thought a re-install from t
On Wed, May 29, 2002 at 09:27:50AM -0700, Dan Trainor wrote:
Hi,
> Being that -CURRENT's C++ compiler is b0rked, how long will it be until
> it's problems have been resolved? I've seen many problems with it
> lately, and it kinda made me worried, almost to the point where I
> thought a re-insta
I have no doubt of the progress that's being made. Anyway, thanks for
the help. Again, keep up the good work.
-dt
-Original Message-
From: Sheldon Hearn [mailto:[EMAIL PROTECTED]] On
Behalf Of Sheldon Hearn
Sent: Wednesday, May 29, 2002 9:49 AM
To: Dan Trainor
Cc: [EMAIL PROTECTED]
S
On 28-May-2002 Julian Elischer wrote:
> Now things are moving again.
> Jonathon Mini and I have cleaned up the patches a bit
> and fixed the more obvious problems..
> from teh point of view of non KSE processes
> (that would be all of them at the moment) it shuold act the
> same as now. Hopeful
I'm new to the list, so please excuse my question If it has already been
asked before.
Being that -CURRENT's C++ compiler is b0rked, how long will it be until
it's problems have been resolved? I've seen many problems with it
lately, and it kinda made me worried, almost to the point where I
tho
On Wed, May 29, 2002 at 12:12:02PM -0400, Alexander Kabaev wrote:
Hi,
> Martin is using GCC 3.1 from ports. It sounds like GCC tries to use some
> library left over from the previous version of GCC, which does not
> provide this symbol. g++13 -v should tell you what parameters GCC passes
> to th
Hi,
I managed to make pccard device driver into loadable module.
http://people.freebsd.org/~takawata/cardmodule.diff
To use this,
1. Apply following patch.(diff from HEAD)
2. Remove 'pccard','pcic','pccbb','cardbus', 'card'
line from configuration file.
3. Add following line to configurat
On Wed, May 29, 2002 at 06:08:58PM +0200, Martin Blapp wrote:
Hi,
> And this doesn't work anymore. I see this with a fresh 3.1 port too now.
Martin, I don't doubt about your answer, but, can you verify you are
indeed using the ports g++ compiler? I can't reproduce the bug here.
Cheers,
--
On Wed, 29 May 2002 18:06:10 +0200
Miguel Mendez <[EMAIL PROTECTED]> wrote:
> I've seen this problem too. I don't know if it has been solved, but
> -CURRENT's C++ compiler has been broken for a while. The workaround
> has been to install the gcc31 port and use it, e.g make
> CXX=/usr/local/bin/g
Hi,
> I've seen this problem too. I don't know if it has been solved, but
> -CURRENT's C++ compiler has been broken for a while. The workaround has
> been to install the gcc31 port and use it, e.g make
> CXX=/usr/local/bin/g++31
And this doesn't work anymore. I see this with a fresh 3.1 port to
On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote:
Hi Martin,
> /usr/ports/editors/openoffice/work/oo_1.0_src/config_office/configure:3620:
> undefined reference to `__gxx_personality_v0'
I've seen this problem too. I don't know if it has been solved, but
-CURRENT's C++ compiler has
Hi all,
I see this configure failure when using the system gcc3.1 or a newer one from
ports. A version from march works.
configure:3602: checking for XOpenDisplay in -lX11
configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib
conftest.C -lX11 1>&5
/var/tmp//ccask2mP.o: In
On 29-May-2002 Seigo Tanimura wrote:
>>> And the p4 depot
>>>
>>> //depot/user/tanimura/ippreempt/...
>>>
>>> The patch is for only i386 at the moment.
>>>
>>> The following is the brief description of the patch:
>
> jhb> I would prefer that this was hung off the preemption stuff I've alread
On 29-May-2002 Peter Wemm wrote:
> M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
> "you must not tsleep!". M_WAITOK conversely means that tsleep should be
> called as needed. Things like malloc still can return NULL even with M_WAITOK
> for non-recoverable scenarios.
No,
On Wed, 29 May 2002, Peter Wemm wrote:
> M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
> "you must not tsleep!". M_WAITOK conversely means that tsleep should be
> called as needed. Things like malloc still can return NULL even with M_WAITOK
> for non-recoverable scenarios
On Wed, 29 May 2002, Peter Wemm wrote:
> Poul-Henning Kamp wrote:
> > Uhm, I'm actually seeing the opposite behaviour as well: after I
> > changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc
> > sleeping...
>
> No, this is a bug in UMA. In certain circumstances, it calls itself
>
On Tue, 28 May 2002, Peter Wemm wrote:
> Richard Wenninger wrote:
> > /usr/src/sys/vm/uma_core.c:1324: could sleep with "UMA lock" locked from
> > /usr/src/sys/vm/uma-core.c:1157
> >
> > Should I be concerned?
>
> Excessively concerned: no. But these are all *real* problems that must
> be fixed.
Howdy,
Disconnecting usr/share/doc/usd/13.viref and usr/share/doc/papers/sysperf
from the build process allowed me to build a -current snapshot.
I found the reference in the CVS logs (2002/05/15 09:29:45 PDT) that c++
isn't being built. This explains the lack of groff and tbl.
There must be some
cvsup'ed about 1 hour ago
in /etc/make.conf
MAKEOBJDIRPREFIX?=/r+d/obj
and with setnev MAKEOBJDIRPREFIX /r+d/obj
make buildworld
...
FATAL: can't create /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/cp-demangle
.o: Permission denied
how can i fix this?
danny
To Unsubscribe: send m
On Wed, May 29, 2002 at 12:50:15AM -0700, Peter Wemm wrote:
> make obj
> make depend
> make
> make install
>
> As long as your /usr/src is up to date, that should save you.
Thank you. But now it fails on building of libncurses, with many:
lib_gen.c:504: `a0' undeclared (first use in this
On Mon, May 27, 2002 at 08:34:18PM +0900, MOCHIZUKI Akihide/??? wrote:
> #define TENDCASE 9
> #define TENDBQUOTE :
> #define TREDIR ;
> #define TWORD <
> #define TIF =
I think that there are problem with awk's printing of numbers.
':' is just '9'+1
so awk tries print numbers from 10 to 15
> >I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL
> >PCI card) I think there are some linuxdrivers but what could be needed for
> >FreeBSD support?
> Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of
> the page).
That's the Speedtouch USB,
Howdy,
I'm trying to build a FreeBSD-current snapshot release with a -current
install as of 28/05/02 1400 GMT and the CVS tree updated to the same date.
I've noticed that when -current is installed into the sandbox, groff isn't
installed, nor is it built prior to building the usr/share/doc/usd fi
Hi,
>I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL
>PCI card) I think there are some linuxdrivers but what could be needed for
>FreeBSD support?
Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of
the page).
--
Bob Bishop +
On Wed, 29 May 2002 16:13:13 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
tanimura> Maybe we can solve both of the issues above by roughly checking if a
tanimura> thread can keep spinning without acquiring any locks, in the similar
tanimura> way as we do for a spin mutex. First, test the fo
Igor Roboul wrote:
> Hello,
> I have trouble building world:
>
> --
> >>> stage 2: cleaning up the object tree
> --
> cd /opt/freebsd/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_AR
Terry Lambert wrote:
> Poul-Henning Kamp wrote:
> > In message <[EMAIL PROTECTED]>, Peter Wemm writes:
> > >As you said, _sleeping_ is the problem. M_WAITOK means "you may sleep if
> > >you like". ie: it is a time bomb waiting for the right low memory condit
ion
> > >which will then explode
Terry Lambert wrote:
> Peter Wemm wrote:
> > > I think _sleeping_ is a problem, but allocation with M_WAITOK
> > > shouldn't be, given it's strange definition of "waiting". This
> > > is one of those hacks that John Baldwin was talking about earlier...
> >
> > As you said, _sleeping_ is the prob
> > As you can see, the patch is trivial, so I have no clue why this wasn't
> > left alone when they modified symfile.c. If I can be bothered I'll
> > submit it to them.
>
> Hmm. Looking at this patch, it seems it's complaining about being
> handed a hex value where it's looking for an address.
64 matches
Mail list logo
