Re: UMA lock
On Tue, May 28, 2002 at 11:36:23PM -0700, 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 condition > > >which will then explode with a 100% authentic crash or lock up. > > > > > >Pretend it said M_SLEEPOK instead of M_WAITOK. > > > > 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... > > I'm with Poul on this one, Peter: M_WAITOK doesn't mean what > you think it means: it's doesn't mean tsleep may be called, > and M_NOWAIT doesn't mean tsleep() _won't_ be called, in > practice. With the same amount of time you spent typing up this Email, you could have checked the code and seen that M_WAITOK _does_ mean that tsleep may be called and that, in effect, M_NOWAIT means that tsleep will not be called. If we have cases where tsleep is called and are M_NOWAIT, then that's not good. M_NOWAIT means: "only allowed to block on a mutex." > It's either incredibly badly named, or it's incredibly badly > implemented -- I would argue the latter, actually, since even > if it's completely orthogonal, you're screwed because it means > you have two call conversion systems, without a WITNESS > intersection to detect deadly embraces. 8-(. > > -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
On Wed, May 29, 2002 at 01:04:00PM -0700, Terry Lambert wrote: > 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, try sleeping; but I realize > > that sleeping for longer than some reasonable time if I'm not getting > > anything to begin with will probably not get me anything at any point > > so tell me the allocation really failed and give me the opportunity to > > clean up before *I* decide what I want to do." > > Up the operating system's wazoo! > > *We* are the programmers. > > *We* know better than *it* whether it's OK to sleep indefinitely > or not. > > If *we* want the allocation to fail after *some reasonable time*, > then *we will damn well set a timer to "some reasonable time"* to > indicate that fact to the OS. > > If *we* do *not* damn well set a timer, then *we* damn well do not > want it to fail, *we* want it to hang either *until it succeeds* or > *until hell freezes over* or *until we manually enter the kernel > debugger to find out why it is hanging*. Then *you* can set *your* timer to hang to infinity. *I* have provided *the* ability to do *that*: tesla# sysctl -A | grep mbuf_wait kern.ipc.mbuf_wait: 32 tesla# sysctl -w kern.ipc.mbuf_wait=0 (Now the mbuf code will behave in such a way that it will hang forever if you call with M_TRYWAIT and cannot allocate anything). However, *I* want to be able to do otherwise, because *I* don't agree with *you*. So *I* will leave my timer to whatever the hell I please and *I* will require callers to check for NULL in all cases, and handle the failure appropriately, because that's what good systems do. If for my particular chunk of code or subsystem, "properly" means "call panic()," then so be it. But if for my particular subsystem it happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be able to catch that failure and handle it after the wait has timed out. If there is code that still uses M_TRYWAIT with the mbuf allocator and does not check for NULL (I believe there is still some of this), well, then, it will simply page fault immediately after it tries dereferencing the NULL pointer and I'll figure it right out. > All these people are bitching about kludging around something by > changing M_WAITOK to M_NOWAIT. > > The kludge is *already there* in M_WAITOK, whether you want it > or not. > > So bitching about this kluge is meaningless: changing it back to > M_WAITOK won't make the little F'er go away, it will just *hide* > the kludge from people to lazy to read the code all the way down, > and know *why* they have to check for a NULL return from a call > that's *supposed to wait* until it's return will *not* be NULL. > > -- Terry > -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
On Wed, May 29, 2002 at 12:20:20AM -0700, Peter Wemm wrote: > M_WAIT for mbufs (not malloc) was an alias for M_WAITOK, and M_DONTWAIT > (also just for mbufs) was an alias for M_NOWAIT. > > You call things and either permit them to tsleep() or you do not. > > 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. Exactly, with one exception: they are no longer aliases. I had renamed (after some discussion) M_WAIT and M_DONTWAIT in the mbuf code to M_TRYWAIT and M_DONTWAIT, respectively, to avoid confusion and avoid mixing the flags with the malloc() flags. > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UMA lock
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, try sleeping; but I realize that sleeping for longer than some reasonable time if I'm not getting anything to begin with will probably not get me anything at any point so tell me the allocation really failed and give me the opportunity to clean up before *I* decide what I want to do." > -- Terry > "Never solve a vast problem in a half-vast way" -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, 30 May 2002, Peter Wemm wrote: > Julian Elischer wrote: > > On Thu, 30 May 2002, Jake Burkholder wrote: > [..] > > > It is much more difficult to ensure that all the register values > > > end up the same on each return from the system call on sparc64, due > > > to the way that register stack works. The current test program > > > will not work at all, because setjmp, longjmp cannot be used to > > > switch the stack in the same way. > > > > The library will not be using setjmp and longjmp in this way but > > instead the setcontext() call that dan wrote for the current thread > > library. If that works it should be enough. > > (I'd like to investigate your comments though... can you explain > > more about why it's a problem? It sure simplifies things on most > > architectures I've done this on.. > > setjmp/longjmp cannot be used to switch stacks on ia64 either, for what > it's worth. This is why libc_r is disabled for ia64 (and I presume > sparc64). I don't really care if setjmp doesn't work, as long as there is some assembler that can be put in the library that can switch a stack/thread. > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
Peter Schultz <[EMAIL PROTECTED]> writes: > Amazing, the obvious. Now I get this: Hmm, I didn't get any more trouble after I fixed the pragma problem. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
Julian Elischer wrote: > On Thu, 30 May 2002, Jake Burkholder wrote: [..] > > It is much more difficult to ensure that all the register values > > end up the same on each return from the system call on sparc64, due > > to the way that register stack works. The current test program > > will not work at all, because setjmp, longjmp cannot be used to > > switch the stack in the same way. > > The library will not be using setjmp and longjmp in this way but > instead the setcontext() call that dan wrote for the current thread > library. If that works it should be enough. > (I'd like to investigate your comments though... can you explain > more about why it's a problem? It sure simplifies things on most > architectures I've done this on.. setjmp/longjmp cannot be used to switch stacks on ia64 either, for what it's worth. This is why libc_r is disabled for ia64 (and I presume sparc64). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Error building ImageMagick
I have been trying to upgrade ImageMagick. It fails with the following in -current, but builds ok on 4.6-RC. I../.. -I/usr/local/include/libxml2 -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include -I/X11 -O -pipe -c -o Geometry.lo `test -f Geometry.cpp || echo './'`Geometry.cpp Geometry.cpp:317: syntax error before `&' token gmake[3]: *** [Geometry.lo] Error 1 gmake[3]: Leaving directory `/usr/ports/graphics/ImageMagick/work/ImageMagick-5.4.5/Magick++/lib' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/ImageMagick/work/ImageMagick-5.4.5/Magick++/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/ImageMagick/work/ImageMagick-5.4.5/Magick++' gmake: *** [all-recursive] Error 1 *** Error code 2 uname: FreeBSD nova.anchoragerescue.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu May 30 11:59:38 AKDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOVA i386 Anybody have a fix? TIA, Beech -- --- Beech Rintoul - SysAdmin - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Sinbad Network Communications \ / - NO HTML/RTF in e-mail | 3101 Penland Parkway #K-38 X - NO Word docs in e-mail | Anchorage, AK 99508-1957 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
On Wed, May 29, 2002 at 11:38:57PM -0500, Peter Schultz wrote: > I'm getting the following error on a just built -current, which was a > fresh install of 5.0-CURRENT-20020519-JPSNAP: Yes, and if you'd been reading the mailing list like you're supposed to you would have already known about this. Kris msg39019/pgp0.pgp Description: PGP signature
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> gnu/usr.bin/binutils/objdump ... bucomm.o(.text+0x391): warning: mktemp() possibly used unsafely; consider using mkstemp() ===> gnu/usr.bin/binutils/ranlib ../libbinutils/libbinutils.a(bucomm.o): In function `make_tempname': bucomm.o(.text+0x391): warning: mktemp() possibly used unsafely; consider using mkstemp() ===> gnu/usr.bin/binutils/readelf ===> gnu/usr.bin/binutils/size /d/home/des/tinderbox/src/contrib/binutils/binutils/size.c:116: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. *** Error code 1 Stop in /d/home/des/tinderbox/src/gnu/usr.bin/binutils/size. *** Error code 1 Stop in /d/home/des/tinderbox/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /d/home/des/tinderbox/src/gnu/usr.bin. *** Error code 1 Stop in /d/home/des/tinderbox/src/gnu. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, 30 May 2002, Jake Burkholder wrote:
> apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
> Julian Elischer said words to the effect of;
>
> >
> >
>
> > Index: bin/ksetest/Makefile
> > ===
> > Index: bin/ksetest/kse_asm.S
> > ===
> > Index: bin/ksetest/kse_threads_test.c
> > ===
>
> I don't know if you intended to commit this test program as well.
> Please do not.
not planing to commit it, (except maybe under 'tools')
>
> > Index: sys/i386/i386/trap.c
> > ===
> > @@ -942,6 +948,23 @@
> > td->td_frame = &frame;
> > if (td->td_ucred != p->p_ucred)
> > cred_update_thread(td);
> > + if (p->p_flag & P_KSES) {
> > + /*
> > +* If we are doing a syscall in a KSE environment,
> > +* note where our mailbox is. There is always the
> > +* possibility that we could do this lazily (in sleep()),
> > +* but for now do it every time.
> > +*/
> > + error = copyin((caddr_t)td->td_kse->ke_mailbox +
> > + offsetof(struct kse_mailbox, current_thread),
> > + &td->td_mailbox, sizeof(void *));
> > + if (error || td->td_mailbox == NULL) {
> > + td->td_mailbox = NULL; /* single thread it.. */
> > + td->td_flags &= ~TDF_UNBOUND;
> > + } else {
> > + td->td_flags |= TDF_UNBOUND;
> > + }
> > + }
> > params = (caddr_t)frame.tf_esp + sizeof(int);
>
> The places where you access user space to setup the linkage for the
> UTS should use fuword and suword instead of copyin and copyout, its
> faster and it makes the code clearer.
Great! I've seen them mentionned several times and thought
"I should see what they are" but never done so..
exactly what I want!
>
> > Index: sys/i386/i386/vm_machdep.c
> > ===
> > --- sys/i386/i386/vm_machdep.c 2002/05/29 07:21:58 #21
> > +++ sys/i386/i386/vm_machdep.c 2002/05/29 07:21:58
> > @@ -283,6 +293,145 @@
> > }
> >
> > void
> > +cpu_thread_setup(struct thread *td)
> > +{
> > +
> > + td->td_pcb =
> > +(struct pcb *)(td->td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1;
> > + td->td_frame = (struct trapframe *)((caddr_t)td->td_pcb - 16) - 1;
> > +}
> > +
> > +struct md_store {
> > + struct pcb mds_pcb;
> > + struct trapframe mds_frame;
> > +};
> > +
> > +void
> > +cpu_save_upcall(struct thread *td, struct kse *newkse)
> > +{
> > +
> > + /* Point the pcb to the top of the stack. */
> > + newkse->ke_mdstorage = malloc(sizeof(struct md_store), M_TEMP,
> > + M_WAITOK);
> > + /* Note: use of M_WAITOK means it won't fail. */
> > + newkse->ke_pcb =
> > + &(((struct md_store *)(newkse->ke_mdstorage))->mds_pcb);
> > + newkse->ke_frame =
> > + &(((struct md_store *)(newkse->ke_mdstorage))->mds_frame);
> > +
> > + /* Copy the upcall pcb. Kernel mode & fp regs are here. */
> > + bcopy(td->td_pcb, newkse->ke_pcb, sizeof(struct pcb));
> > +
> > + /* This copies most of the user mode register values. */
> > + bcopy(td->td_frame, newkse->ke_frame, sizeof(struct trapframe));
> > +}
>
> ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
> struct mdkse, like mdproc. The fact that the storage is large enough
> to warrant using malloc is machine dependent, so it should not be a
> pointer. I would be inclined to just embed a trapframe.
e... ke_mdstorage is just a pointer to the mdstorage
as are the others.. I don't want to include an md structure into
the KSE.. it's big enough as it is.. Every process has a KSE
but only KSE-mode processes have the extra mdstorage area.
Do you feel strongly about this?
>
> The pcb should not be needed at all here; all of the meaningful kernel
> mode register values are set below. Capturing the whole execution
> context at the time of the kse_new call (floating point registers,
> debug registers) may be expensive and I don't think is worth doing.
Yes I started out with the PCB there but as I went I found I was needing
less and less of it. I even have a comment to that effect somewhere..
At this stage I still have it only because I wanted to make sure that
I had good defaults for anything that I wasn't sure about..
Also I haven't figured out what to do about FP registers
and I may want to stuff them there at some stage...
(not sure yet)
>
> The whole trick of a system call that returns multiple times is
> dubious. The fact that it works at all is machine dependent; for
> sparc64 it needs wierd hacks in the kernel like is done for vfork.
> It would be better to just register an upcall stack and en
Re: Seeking OK to commit KSE MIII-again
apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
Julian Elischer said words to the effect of;
>
>
> ok, but does anyone other than john (who has commented) have any comments
> about the logic and work in the change?
>
> I'm working on his comments but comments by others would sure be
> appreciated..
> especially if they actually comment on what I'm trying to do..
>
> If I can get the changes for the other architectures done,
> I'd like to commit this weekend. HOPEFULLY it shouldn't
> affect normal operations but of course the testing done by two people
> can't hope to equal that which will be done in teh first 24 hours
> once it's committed :-)
>
> once again:
>
> the diffs are at:
> http://people.freebsd.org/~peter/kse.diff
> and
> http://people.freebsd.org/~julian/thediff
> and the diffs I need for other architectures are versions of:
>
> sys/i386/i386/genassym.c (small)
> sys/i386/i386/machdep.c (1 line)
> sys/i386/i386/swtch.s (a few lines)
> sys/i386/i386/trap.c (small)
> sys/i386/i386/vm_machdep.c (largly new functions, we could stub them)
> sys/i386/include/kse.h (new file)
> sys/i386/linux/linux_machdep.c (one line)
>
> Largely these need to be written by someone who is intimately aquainted
> with the register set of the machine in question and knows
> what registers need to be saved to restore a user context correctly.
>
> Index: bin/ksetest/Makefile
> ===
> Index: bin/ksetest/kse_asm.S
> ===
> Index: bin/ksetest/kse_threads_test.c
> ===
I don't know if you intended to commit this test program as well.
Please do not.
> Index: sys/i386/i386/trap.c
> ===
> @@ -942,6 +948,23 @@
> td->td_frame = &frame;
> if (td->td_ucred != p->p_ucred)
> cred_update_thread(td);
> + if (p->p_flag & P_KSES) {
> + /*
> + * If we are doing a syscall in a KSE environment,
> + * note where our mailbox is. There is always the
> + * possibility that we could do this lazily (in sleep()),
> + * but for now do it every time.
> + */
> + error = copyin((caddr_t)td->td_kse->ke_mailbox +
> + offsetof(struct kse_mailbox, current_thread),
> + &td->td_mailbox, sizeof(void *));
> + if (error || td->td_mailbox == NULL) {
> + td->td_mailbox = NULL; /* single thread it.. */
> + td->td_flags &= ~TDF_UNBOUND;
> + } else {
> + td->td_flags |= TDF_UNBOUND;
> + }
> + }
> params = (caddr_t)frame.tf_esp + sizeof(int);
The places where you access user space to setup the linkage for the
UTS should use fuword and suword instead of copyin and copyout, its
faster and it makes the code clearer.
> Index: sys/i386/i386/vm_machdep.c
> ===
> --- sys/i386/i386/vm_machdep.c2002/05/29 07:21:58 #21
> +++ sys/i386/i386/vm_machdep.c2002/05/29 07:21:58
> @@ -283,6 +293,145 @@
> }
>
> void
> +cpu_thread_setup(struct thread *td)
> +{
> +
> + td->td_pcb =
> + (struct pcb *)(td->td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1;
> + td->td_frame = (struct trapframe *)((caddr_t)td->td_pcb - 16) - 1;
> +}
> +
> +struct md_store {
> + struct pcb mds_pcb;
> + struct trapframe mds_frame;
> +};
> +
> +void
> +cpu_save_upcall(struct thread *td, struct kse *newkse)
> +{
> +
> + /* Point the pcb to the top of the stack. */
> + newkse->ke_mdstorage = malloc(sizeof(struct md_store), M_TEMP,
> + M_WAITOK);
> + /* Note: use of M_WAITOK means it won't fail. */
> + newkse->ke_pcb =
> + &(((struct md_store *)(newkse->ke_mdstorage))->mds_pcb);
> + newkse->ke_frame =
> + &(((struct md_store *)(newkse->ke_mdstorage))->mds_frame);
> +
> + /* Copy the upcall pcb. Kernel mode & fp regs are here. */
> + bcopy(td->td_pcb, newkse->ke_pcb, sizeof(struct pcb));
> +
> + /* This copies most of the user mode register values. */
> + bcopy(td->td_frame, newkse->ke_frame, sizeof(struct trapframe));
> +}
ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
struct mdkse, like mdproc. The fact that the storage is large enough
to warrant using malloc is machine dependent, so it should not be a
pointer. I would be inclined to just embed a trapframe.
The pcb should not be needed at all here; all of the meaningful kernel
mode register values are set below. Capturing the whole execution
context at the time of the kse_new call (floating point registers,
debug registers) may be expensive and I don't think is worth doing.
The whole trick of a system
make kernel broken at dev/xe/if_xe_pccard.c
cc -O -pipe -march=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-fo rmat -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /usr/src/sys/dev/xe/if_xe_pccard.c In file included from /usr/src/sys/dev/xe/if_xe_pccard.c:53: card_if.h:166: syntax error before "pccard_product_match_fn" card_if.h:166: warning: function declaration isn't a prototype card_if.h:169: syntax error before "pccard_product_match_fn" card_if.h:170: warning: function declaration isn't a prototype card_if.h: In function `CARD_DO_PRODUCT_LOOKUP': card_if.h:172: `bus' undeclared (first use in this function) card_if.h:172: (Each undeclared identifier is reported only once card_if.h:172: for each function it appears in.) card_if.h:173: `dev' undeclared (first use in this function) card_if.h:173: `tab' undeclared (first use in this function) card_if.h:173: `ent_size' undeclared (first use in this function) card_if.h:173: `matchfn' undeclared (first use in this function) *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Solved: libstdc++ problem with recent CURRENT
hi Peter, > To be sure we're all on the same page, simply uncommenting stubs.c solves > your problem with no libm changes, right? Exactly. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Solved: libstdc++ problem with recent CURRENT
Martin Blapp wrote:
> If we add this patch, we should also add the bits in libm:
>
> #ifndef HAVE_SQRTL
> long double
> sqrtl(long double x)
> {
> return sqrt((double) x);
> }
> #endif
[..]
> or we just compile stubs.c in and the gcc provided bits.
> But I guess we would also not to link against libm then.
>
> root@fuchur:/usr/src# diff -ruN gnu/lib/libstdc++/Makefile.orig
> gnu/lib/libstdc++/Makefile
> --- gnu/lib/libstdc++/Makefile.orig Thu May 30 23:35:38 2002
> +++ gnu/lib/libstdc++/Makefile Thu May 30 23:32:19 2002
> @@ -32,7 +32,7 @@
> valarray-inst.cc ext-inst.cc
>
> # C parts of math
> -SRCS+= nan.c signbit.c signbitf.c signbitl.c # stubs.c
> +SRCS+= nan.c signbit.c signbitf.c signbitl.c stubs.c
>
> # Embedded copy of libsupc++
> SRCS+= del_op.cc del_opnt.cc del_opv.cc del_opvnt.cc \
>
> But now it's working ...
You know, I think I'd rather activate the stubs.c file than patch libm.
If libm is going to provide real "long double" functions, then it should
provide real ones, not faked lower precision ones.
stubs.c fills in the blanks for the parts that libm doesn't provide,
according to config.h. We can even add ifdefs to the config.h file if we
have some arches that provide the long double versions and others that do
not.
To be sure we're all on the same page, simply uncommenting stubs.c solves
your problem with no libm changes, right?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current as guest of VMWare2
On Thu, May 30, 2002 at 11:46:50PM +0200, Nicolas Souchu wrote: > Hi folks, > > I'm currently trying to install -current as a guest OS of VMWare2 > running under 4.6RC. > > The problem is that it works correctly except that after some > processing, the VMWare2 engine slows down the OS incredibly. To > get things back to a correct speed I have to suspend the VMWare > session then restore it. > > I also have a VMWare2 guest 4.6RC (running on the same 4.6RC host) > which works like a charm. > > I've compiled with the following machine file: > > Any idea? > > Nicholas Try cpu I386_CPU and let me know how it works out! I'm trying to do something similar. Thanks, Bosko. > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.343 2002/05/22 19:00:48 obrien Exp $ > > machine i386 > cpu I486_CPU > cpu I586_CPU > ident RATZ > maxusers 0 > Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current as guest of VMWare2
There is a patch to fix this problem that I posted to the list sometime ago. I don't have it handy right now, but you can find it in the mailing list archive... Glenn G. On Thu, 30 May 2002 23:46:50 +0200, "Nicolas Souchu" <[EMAIL PROTECTED]> said: > Hi folks, > > I'm currently trying to install -current as a guest OS of VMWare2 > running under 4.6RC. > > The problem is that it works correctly except that after some > processing, the VMWare2 engine slows down the OS incredibly. To > get things back to a correct speed I have to suspend the VMWare > session then restore it. > > I also have a VMWare2 guest 4.6RC (running on the same 4.6RC host) > which works like a charm. > > I've compiled with the following machine file: > > Any idea? > > Nicholas > > > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.343 2002/05/22 19:00:48 > obrien Exp $ > > machine i386 > cpu I486_CPU > cpu I586_CPU > ident RATZ > maxusers0 > > #To statically compile in device wiring instead of /boot/device.hints > hints "RATZ.hints"#Default places to look for > devices. > > makeoptions DEBUG=-g#Build kernel with gdb(1) debug > symbols > > options INET#InterNETworking > options INET6 #IPv6 communications protocols > options FFS #Berkeley Fast Filesystem > options SOFTUPDATES #Enable FFS soft updates > support > options UFS_DIRHASH #Improve performance on big > directories > options MD_ROOT #MD is a potential root device > options NFSCLIENT #Network Filesystem Client > options NFSSERVER #Network Filesystem Server > options NFS_ROOT#NFS usable as root device, > requires NFSCLIENT > options MSDOSFS #MSDOS Filesystem > options CD9660 #ISO 9660 Filesystem > options PROCFS #Process filesystem (requires > PSEUDOFS) > options PSEUDOFS#Pseudo-filesystem framework > options COMPAT_43 #Compatible with BSD 4.3 [KEEP > THIS!] > options SCSI_DELAY=15000#Delay (in ms) before probing > SCSI > options KTRACE #ktrace(1) support > options SYSVSHM #SYSV-style shared memory > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options P1003_1B#Posix P1003_1B real-time > extensions > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV# install a CDEV entry in /dev > > # Debugging for use in -current > options DDB #Enable the kernel debugger > options INVARIANTS #Enable calls of extra sanity > checking > options INVARIANT_SUPPORT #Extra sanity checks of > internal structures, required by INVARIANTS > #optionsWITNESS #Enable checks to detect > deadlocks and cycles > #optionsWITNESS_SKIPSPIN#Don't run witness on spinlocks > for speed > options ALT_BREAK_TO_DEBUGGER > > device isa > device pci > #optionsPCI_ENABLE_IO_MODES # Enable pci resources left off > by a "lazy BIOS" > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device atapicd # ATAPI CDROM drives > options ATA_STATIC_ID #Static device numbering > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc 1 # At keyboard controller > device atkbd # at keyboard > device psm # psm mouse > > device vga # VGA screen > > # splash screen/screen saver > device splash > > # syscons is the default console driver, resembling an SCO console > device sc 1 > > # Enable this for the pcvt (VT220 compatible) console driver > #device vt > #optionsXSERVER # support for X server on a vt > console > #optionsFAT_CURSOR # start with block cursor > > # Floating point support - do not disable. > device npx > > # Power management support (see NOTES for more options) > device apm > # Add suspend/resume support for the i8254. > device pmtimer > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > > # Parallel port > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip# TCP/IP over parallel > device ppi # Parallel port interface device > #dev
Re: Solved: libstdc++ problem with recent CURRENT
Seems I was wrong. Uhm. It's late here... Anyway, I've really
running it now.
If we add this patch, we should also add the bits in libm:
#ifndef HAVE_SQRTL
long double
sqrtl(long double x)
{
return sqrt((double) x);
}
#endif
#ifndef HAVE_COSL
long double
cosl(long double x)
{
return cos((double) x);
}
#endif
#ifndef HAVE_SINL
long double
sinl(long double x)
{
return sin((double) x);
}
#endif
or we just compile stubs.c in and the gcc provided bits.
But I guess we would also not to link against libm then.
root@fuchur:/usr/src# diff -ruN gnu/lib/libstdc++/Makefile.orig
gnu/lib/libstdc++/Makefile
--- gnu/lib/libstdc++/Makefile.orig Thu May 30 23:35:38 2002
+++ gnu/lib/libstdc++/Makefile Thu May 30 23:32:19 2002
@@ -32,7 +32,7 @@
valarray-inst.cc ext-inst.cc
# C parts of math
-SRCS+= nan.c signbit.c signbitf.c signbitl.c # stubs.c
+SRCS+= nan.c signbit.c signbitf.c signbitl.c stubs.c
# Embedded copy of libsupc++
SRCS+= del_op.cc del_opnt.cc del_opv.cc del_opvnt.cc \
But now it's working ...
root@fuchur:/usr/src/gnu/lib/libstdc++# nm /usr/lib/libstdc++.a | grep cosl
002a T cosl
root@fuchur:/usr/src/gnu/lib/libstdc++# nm /usr/lib/libstdc++.a | grep sqrtl
016c T sqrtl
root@fuchur:/usr/src/gnu/lib/libstdc++# nm /usr/lib/libstdc++.a | grep sinl
0134 T sinl
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current as guest of VMWare2
Hi folks, I'm currently trying to install -current as a guest OS of VMWare2 running under 4.6RC. The problem is that it works correctly except that after some processing, the VMWare2 engine slows down the OS incredibly. To get things back to a correct speed I have to suspend the VMWare session then restore it. I also have a VMWare2 guest 4.6RC (running on the same 4.6RC host) which works like a charm. I've compiled with the following machine file: Any idea? Nicholas # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.343 2002/05/22 19:00:48 obrien Exp $ machine i386 cpu I486_CPU cpu I586_CPU ident RATZ maxusers0 #To statically compile in device wiring instead of /boot/device.hints hints "RATZ.hints"#Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #optionsWITNESS #Enable checks to detect deadlocks and cycles #optionsWITNESS_SKIPSPIN#Don't run witness on spinlocks for speed options ALT_BREAK_TO_DEBUGGER device isa device pci #optionsPCI_ENABLE_IO_MODES # Enable pci resources left off by a "lazy BIOS" # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 # At keyboard controller device atkbd # at keyboard device psm # psm mouse device vga # VGA screen # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc 1 # Enable this for the pcvt (VT220 compatible) console driver #device vt #optionsXSERVER # support for X server on a vt console #optionsFAT_CURSOR # start with block cursor # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # ISA Ethernet NICs. pccard nics included. device lnc # NE2100, NE32-VL Lance Ethernet cards # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop# Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp 1 # Kernel PPP device tun #
Re: Seeking OK to commit KSE MIII
John Baldwin wrote:
> This is your opinion not gospel truth. The reason I and others leave out
> braces except when they are needed is to minimize the number of wasted
> vertical space so that more code can fit on a screen at a time. This is
> the same reason for using
>
> if (foo) {
> ...
> }
>
> Instead of:
>
> if (foo)
> {
> ...
> }
Actually, that's a tools issue; specifically, it has to do with
"%" and "$" in "vi".
Just like:
int
foo( x)
instead of:
int foo(x)
Has todo with "grep ^name " for function
declatation finding, vs. references.
As for "extra braces", I've seen people do:
#if foo /* { */
...
#else /* !foo } { */
#endif /* !foo } */
To let people use statement start/end block matching on "#if", too.
Our tools dictate a lot of what people say constitutes "style", but
what really works out to be "efficient use of tools".
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Solved: libstdc++ problem with recent CURRENT
http://people.freebsd.org/~mbr/patches/patch-libstd++::config.h This patch fixes the problem. --- gnu/lib/libstdc++/c++config.h.orig Wed May 29 02:45:51 2002 +++ gnu/lib/libstdc++/c++config.h Thu May 30 22:49:07 2002 @@ -420,7 +420,7 @@ /* #undef _GLIBCPP_HAVE_COSHL */ /* Define if you have the cosl function. */ -/* #undef _GLIBCPP_HAVE_COSL */ +#define _GLIBCPP_HAVE_COSL 1 /* Define if you have the drand48 function. */ #define _GLIBCPP_HAVE_DRAND48 1 @@ -612,13 +612,13 @@ /* #undef _GLIBCPP_HAVE_SINHL */ /* Define if you have the sinl function. */ -/* #undef _GLIBCPP_HAVE_SINL */ +#define _GLIBCPP_HAVE_SINL 1 /* Define if you have the sqrtf function. */ #define _GLIBCPP_HAVE_SQRTF 1 /* Define if you have the sqrtl function. */ -/* #undef _GLIBCPP_HAVE_SQRTL */ +#define _GLIBCPP_HAVE_SQRTL 1 /* Define if you have the strtof function. */ /* #undef _GLIBCPP_HAVE_STRTOF */ --- gnu/lib/libstdc++/config.h.orig Fri May 10 10:54:42 2002 +++ gnu/lib/libstdc++/config.h Thu May 30 22:45:01 2002 @@ -343,7 +343,7 @@ /* #undef HAVE_COSHL */ /* Define if you have the cosl function. */ -/* #undef HAVE_COSL */ +#define HAVE_COSL 1 /* Define if you have the drand48 function. */ #define HAVE_DRAND48 1 @@ -535,13 +535,13 @@ /* #undef HAVE_SINHL */ /* Define if you have the sinl function. */ -/* #undef HAVE_SINL */ +#define HAVE_SINL 1 /* Define if you have the sqrtf function. */ #define HAVE_SQRTF 1 /* Define if you have the sqrtl function. */ -/* #undef HAVE_SQRTL */ +#define HAVE_SQRTL 1 /* Define if you have the strtof function. */ /* #undef HAVE_STRTOF */ Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: BuildWorld is broken...
This is the repeated error I've gotten from my attempts to build from current (cvsup'd) sources - any comments, suggestions greatly appreciated. -- >>> stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks par-includes ===> share/info cd /usr/src/share/info; make buildincludes; make installincludes ===> include cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo "$COPYRIGHT" > osreldate.h;echo "#ifdef _KERNEL" >> osreldate.h; echo '#error "/usr/include/osreldate.h cannot be used in the kernel, use sys/param.h"' >> osreldate.h; echo "#else" >> osreldate.h; echo \#'undef __FreeBSD_version' >> osreldate.h; echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h; echo "#endif" >> osreldate.h *** Signal 12 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- - End Transmission - Sometimes you stop at the edge - sometimes you don't -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "Ideas are more powerful than guns. We would not let our enemies have guns, why should we let them have ideas." Joseph Stalin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII
:...
:}
:
:Instead of:
:
:if (foo)
:{
:...
:}
:
:However, the real pain here is that basically people go and modify code
:they aren't even touching. If you are modifying the condition of an if()
:but not the body then the extra braces are just gratuitous. You did this
:when you went and pushed down Giant in a bunch of the syscalls adding {}'s
:around code you weren't directly touching. Basically then it is rather
:tempting to just back them back out again in the next commit to that area
:of the code and we keep cycling back and forth which is pretty stupid.
:
:I would just prefer that we leave code as it is unless we actually require
:the extra braces because there are multiple statements in the body. If
:you will commit to that I will commit to not removing extra braces that
:offend my sensibilities in my commits. :)
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
I will adjust bracing on code that I am working on. It is hardly
gratuitous. It makes it far easier for me to read and that's important
because I don't like to miss things in the code I'm working on.
You seem to think that the 'wasted vertical space' is a bad thing, as if
human beings are, what, compilers? We are human beings. It is far more
important for the code to well commented and readable, not squeezed
together like a jack in the box in a way that only the original author
can parse. It does not make anyone's life easier trying to read
uncommented third party code and it certainly does not give one a
quicker understanding of a piece of code just because its been squeezed
together to all fit on one screen. I find squeezed code to be almost
*UNREADABLE*, in fact. It takes me far longer to understand a bit of
squeezed code then it does for me to understand well-braced and commented
code.
From my point of view, anyone who is working on a piece of code to
improve it has a right to make adjustments to the syntax, within
reason, to make it easier to understand and operate on the code. If we
try to impose one specific, set-in-stone way of doing things on the
entire developer base we end up with lost interest and a lack of
evolution in the code.
I can only repeat that when you try to apply a rule unconditionally,
even to minor, unremarkable things, and let that govern your expectations
in life, that the only result you will get is friction and a lessening of
interest in the project. It's like crying wolf over and over again.
Save your arguments for the cases where it really matters and you might
get better results.
I'm going to leave you with one more comment. I have been thanked on
many occassions by engineers and programmers working for all sorts of
companies that delve into the FreeBSD kernel. They have thanked me
for providing clear comments and readable code that has allowed them
to come in blind and quickly ramp up their understanding of our kernel and
their ability to modify it. A lot of what I do I do not because *I*
need it, personally, but because it helps the myrid engineers, sysops,
and others who work with our system. You may not appreciate it but
plenty of others do and frankly I find that to be far more important
then the occassional merge of otherwise unmaintained code between the
BSDs. I've heard the 'easier to merge with other BSDs' argument many
times, but as far as I can tell the extra work involved pales in comparison
to the time saved by all the third parties that use or work on the FreeBSD
kernel. Using the argument blindly as a justification to stop code
evolution is just plain a dumb idea.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
Julian Elischer wrote: > > > ok, but does anyone other than john (who has commented) have any comments > about the logic and work in the change? If you want final commit approval/objections, you really need to either include or go to developers@ instead since they're the ones dealing with actual commit process. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libstdc++ problem with recent CURRENT
Martin Blapp wrote: > > Hi David, Please include me in these messages regarding the libraries in the -current build, this is almost certainly my breakage since I committed it. > I've now problems linking with stlport lib with our native g++: > > ../unxfbsd.pro/obj/syshelp.o -lc_r -lm -lstlport_gcc -lsupc++ -Wl,-Bdynamic > -lstlport_gcc -lc_r -lsupc++ > > /usr/ports/editors/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/lib/libs tlport_gcc.so: > undefined reference to `sqrtl' > /usr/ports/editors/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/lib/libs tlport_gcc.so: > undefined reference to `sinl' > /usr/ports/editors/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/lib/libs tlport_gcc.so: > undefined reference to `cosl' > > There seem to be some math bits missing in the OS installed > version. They exist in the gcc3.1 port from march. The most likely culprit here is that David and I configured something differently or ./configure found something different on our systems when generating config.h for the library. I'll go back over this again. I'm pretty sure we had different locale settings, but I'm a little suprised about the math differences. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, 30 May 2002, Bernd Walter wrote: > > Largely these need to be written by someone who is intimately aquainted > > with the register set of the machine in question and knows > > what registers need to be saved to restore a user context correctly. > > I can do the alpha part tomorrow unless someone else already startet. THANKS! It shouldn't be too hard.. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, May 30, 2002 at 09:20:57AM -0700, Julian Elischer wrote: > ok, but does anyone other than john (who has commented) have any comments > about the logic and work in the change? > > I'm working on his comments but comments by others would sure be > appreciated.. > especially if they actually comment on what I'm trying to do.. > > If I can get the changes for the other architectures done, > I'd like to commit this weekend. HOPEFULLY it shouldn't > affect normal operations but of course the testing done by two people > can't hope to equal that which will be done in teh first 24 hours > once it's committed :-) > > once again: > > the diffs are at: > http://people.freebsd.org/~peter/kse.diff > and > http://people.freebsd.org/~julian/thediff > and the diffs I need for other architectures are versions of: > > sys/i386/i386/genassym.c (small) > sys/i386/i386/machdep.c (1 line) > sys/i386/i386/swtch.s (a few lines) > sys/i386/i386/trap.c (small) > sys/i386/i386/vm_machdep.c (largly new functions, we could stub them) > sys/i386/include/kse.h (new file) > sys/i386/linux/linux_machdep.c (one line) > > Largely these need to be written by someone who is intimately aquainted > with the register set of the machine in question and knows > what registers need to be saved to restore a user context correctly. I can do the alpha part tomorrow unless someone else already startet. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FW: Re: Error with post 1.1 release Postfix and Cyrus -Possible Bug in VM system
Do we have anyone working on the VM system that could look at this? - Forwarded message from Wietse Venema <[EMAIL PROTECTED]> - Date: Thu, 30 May 2002 12:49:10 -0400 (EDT) Reply-To: Postfix users <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] (Wietse Venema) To: Postfix users <[EMAIL PROTECTED]> Subject: Re: Error with post 1.1 release Postfix and Cyrus X-Mailer: ELM [version 2.4ME+ PL82 (25)] Sender: [EMAIL PROTECTED] You're somehow still running qmgr code that speaks the protocol from before 20020514. To find the file, # find / \( -name qmgr -o -name nqmgr \) -ls But you may not find this file. After upgrading Postfix I very, very, occasionally find that FreeBSD will execute a new process from an old file that was just replaced. Postfix always installs executables by using "mv newfile oldfile". At this time, the old file may still be executing, and the parent process is always executing (the Postfix master daemon). I suspect an obscure VM system bug. "postfix reload" does not seem to cure this condition. The problem goes away after "postfix stop" then "postfix start", which terminates the parent process. This has happened to me only twice over the past year. My server and workstations run FreeBSD versions 4.1 - 4.4. I haven't found the time and energy to debug this. Wietse - To unsubscribe, send mail to [EMAIL PROTECTED] with content (not subject): unsubscribe postfix-users - End forwarded message - -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Seeking OK to commit KSE MIII-again
ok, but does anyone other than john (who has commented) have any comments about the logic and work in the change? I'm working on his comments but comments by others would sure be appreciated.. especially if they actually comment on what I'm trying to do.. If I can get the changes for the other architectures done, I'd like to commit this weekend. HOPEFULLY it shouldn't affect normal operations but of course the testing done by two people can't hope to equal that which will be done in teh first 24 hours once it's committed :-) once again: the diffs are at: http://people.freebsd.org/~peter/kse.diff and http://people.freebsd.org/~julian/thediff and the diffs I need for other architectures are versions of: sys/i386/i386/genassym.c (small) sys/i386/i386/machdep.c (1 line) sys/i386/i386/swtch.s (a few lines) sys/i386/i386/trap.c (small) sys/i386/i386/vm_machdep.c (largly new functions, we could stub them) sys/i386/include/kse.h (new file) sys/i386/linux/linux_machdep.c (one line) Largely these need to be written by someone who is intimately aquainted with the register set of the machine in question and knows what registers need to be saved to restore a user context correctly. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
Dag-Erling Smorgrav wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > >>* Peter Wemm <[EMAIL PROTECTED]> [020530 01:01] wrote: >> >>>gcc-3.1 appears to have broken >>>#pragma weak foo = bar >> >>What's the correct way to do this now? > > > #pragma weak foo = "bar" > > as you'd have guessed if you'd bothered to read the error message and > look at the code > > DES Amazing, the obvious. Now I get this: rm -f ../../../../../lib/GL/mesa/src/translate.o unshared/../../../../../lib/GL/mesa/src/translate.o LD_LIBRARY_PATH=../../../../../exports/lib cc -c -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../../../exports/include/X11 -I../../../../../include/extensions -I../../../../../extras/Mesa/src/OSmesa -I../../../../../extras/Mesa/src -I../../../../../extras/Mesa/include -I../../../../.. -I../../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL ../../../../../lib/GL/mesa/src/translate.c -o unshared/../../../../../lib/GL/mesa/src/translate.o Assembler messages: FATAL: can't create unshared/../../../../../lib/GL/mesa/src/translate.o: No such file or directory *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/GL/mesa/src/OSmesa. The make needs to go back one more level: unshared/../../../../../../lib/GL/mesa/src/translate.o How to do this, I do not know. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII
On 29-May-2002 Matthew Dillon wrote:
>: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
>:has braces.. it just helps me find the end of the if statement.
>:The "if" statement in question was rewritten as part of KSE
>:so Adding the braces on the else clause doesn't seem 'out of scope'
>:to me.. It's not a tremendous obfuscation, because the clause
>:in question needs to be considered to understand the change..
>
> I do this too. My rule for if() statements 'if (exp) stmt1 else stmt2'
> in the FreeBSD codebase is:
>
> * If or is multi-line, or is multi-line, then
> braces are used around both statements, period.
>
> Multi-line means: multiple lines inclusive of any comments, not just
> the pure C part of it.
>
> This is wrong:
This is your opinion not gospel truth. The reason I and others leave out
braces except when they are needed is to minimize the number of wasted
vertical space so that more code can fit on a screen at a time. This is
the same reason for using
if (foo) {
...
}
Instead of:
if (foo)
{
...
}
However, the real pain here is that basically people go and modify code
they aren't even touching. If you are modifying the condition of an if()
but not the body then the extra braces are just gratuitous. You did this
when you went and pushed down Giant in a bunch of the syscalls adding {}'s
around code you weren't directly touching. Basically then it is rather
tempting to just back them back out again in the next commit to that area
of the code and we keep cycling back and forth which is pretty stupid.
I would just prefer that we leave code as it is unless we actually require
the extra braces because there are multiple statements in the body. If
you will commit to that I will commit to not removing extra braces that
offend my sensibilities in my commits. :)
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"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: XFree86-4-libraries build error
Alfred Perlstein <[EMAIL PROTECTED]> writes: > * Peter Wemm <[EMAIL PROTECTED]> [020530 01:01] wrote: > > gcc-3.1 appears to have broken > > #pragma weak foo = bar > What's the correct way to do this now? #pragma weak foo = "bar" as you'd have guessed if you'd bothered to read the error message and look at the code DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What is Tinderbox?
rob wrote: > Pardon my ignorant question. What is Tinderbox? My guess is that its a > special machine for doing some testing. Rob. A tinderbox is a machine dedicated to building something big and complex. Here's a good example from the mozilla project. http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Someone likes you!
Believe it! You have a secret admirer! Just click to http://www.SomeoneLikesYou.com to find out who! Email address: [EMAIL PROTECTED] Secret code: opn6wj See you soon! Best wishes, The SomeoneLikesYou Matchmaker No Spam Policy: Unlike some other sites, SomeoneLikesYou will never send you spam or junk email. You have received this notice at the request of someone you know who has told us they like you! If you would like to keep anyone from sending you such a notice, please go to http://www.SomeoneLikesYou.com/unsubscribe.html
What is Tinderbox?
Pardon my ignorant question. What is Tinderbox? My guess is that its a special machine for doing some testing. Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Port: gcc31-3.1
Hi, > /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/cc1: No such file or > directory A path is wrong in the port. I worked around this with: cp -r /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1.1\* \ /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1 I think David will fix the port soon. Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld is broken(src/bin/sh)
I don't know why, but /usr/bin/awk is hardlinked to /usr/bin/nawk on my notepc. So, I make that /usr/bin/awk is hardlinked to /usr/bin/gawk( not /usr/bin/nawk). And buildworld on my notepc(5-current) is fine. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD Port: gcc31-3.1
OK the gcc31 builds OK for me on FreeBSD 5.0 Current but when I try to make install this happens: ===> Generating temporary packing list /usr/libexec/elf/strip: /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/cc1: No such file or directory *** Error code 1 Stop in /usr/ports/lang/gcc31. *** Error code 1 Stop in /usr/ports/lang/gcc31. ** Command failed: make ** Fix the installation problem and try again. ** The following packages were not installed or upgraded (*:skipped / !:failed) ! lang/gcc31(install error) su-2.05a# does anyone have any idea? my uname -a: FreeBSD Amnesiac 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun May 26 03:26:38 CEST 2002 root@Amnesiac:/usr/obj/usr/src/sys/Linn i386 /John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII
On Thu, May 30, 2002 at 12:43:22AM -0700, Terry Lambert wrote: Hi, > Rules are what seperate us from the apes. And even with them, some computer users still resemble them ;-)º > Apes with Internet access, degrees in CS, a working knowledge of > CVS, an ability to code, mailing list access, and commit bits. Put a large enough number of apes to type in emacs, and you'll eventually end up with a kernel, albeit one with a borken VM subsystem :-) Now to keep on-topic... > Hell, if it makes things easier for Julian to put in more code, > then it's OK with me. He's done the lion's share of work on > getting KSE into FreeBSD so far (IMO). Agreed. I also completely agree with what Matt said in another message about coding style, although it was my idea that it was obvious enough for everybody already, as per style(9) Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg38989/pgp0.pgp Description: PGP signature
Someone likes you!
Believe it! You have a secret admirer! Just click to http://www.SomeoneLikesYou.com to find out who! Email address: [EMAIL PROTECTED] Secret code: opn6wj (Note: This is NOT your password!) See you soon! Best wishes, The SomeoneLikesYou Matchmaker No Spam Policy: Unlike some other sites, SomeoneLikesYou will never send you spam or junk email. You have received this notice at the request of someone you know who has told us they like you! If you would like to keep anyone from sending you such a notice, please go to http://www.SomeoneLikesYou.com/unsubscribe.html
libstdc++ problem with recent CURRENT
Hi David, I've now problems linking with stlport lib with our native g++: ../unxfbsd.pro/obj/syshelp.o -lc_r -lm -lstlport_gcc -lsupc++ -Wl,-Bdynamic -lstlport_gcc -lc_r -lsupc++ /usr/ports/editors/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/lib/libstlport_gcc.so: undefined reference to `sqrtl' /usr/ports/editors/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/lib/libstlport_gcc.so: undefined reference to `sinl' /usr/ports/editors/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/lib/libstlport_gcc.so: undefined reference to `cosl' There seem to be some math bits missing in the OS installed version. They exist in the gcc3.1 port from march. CURRENT libstdc++ - # nm /usr/lib/libstdc++.a | grep sqrtl CURRENT GCC31 port from march - # nm /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/libstdc++.a | grep sqrtl 018a T sqrtl STABLE GCC31 port from mai25 # nm /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1/libstdc++.a | grep sqrtl 018a T sqrtl Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
> > > #pragma weak foo = bar
> >
> > What's the correct way to do this now?
>
> I dont know. :-( There are hacks that can work around it, but I think this
> is unintentional breakage. I tried changing this:
> #pragma weak foo = bar
> to
> __weak_reference(bar, foo);
void f () __attribute__ ((weak, alias ("__f")));
(But that may come to the same thing).
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
I just installed recent CURRENT, and the problem is gone ! It only exists now in the ports version, and it happens both on STABLE and CURRENT: GCC3.1 port on STABLE, fresh install bash-2.05a# /usr/local/bin/g++31 -v -o conftest -O -pipe -L/usr/X11R6/lib conftest.C -lX11 Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/specs Configured with: ./..//gcc-20020521/configure --disable-nls --with-gnu-as --with-gnu-ld --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1/include/g++ --disable-libgcj --disable-shared --prefix=/usr/local i386-portbld-freebsd4.5 Thread model: posix gcc version 3.1.1 20020521 (prerelease) [FreeBSD] /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=1 -D__FreeBSD__=4 -Dunix -D__ELF__ -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=4 -D__unix__ -D__ELF__ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__ELF__ conftest.C -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase conftest.C -O -version -o - | as -v -o /var/tmp//ccLulSZf.o GNU CPP version 3.1.1 20020521 (prerelease) [FreeBSD] (cpplib)GNU assembler version 2.11.2 20010719 [FreeBSD] (i386-unknown-freebsd4) using BFD version 2.11.2 20010719 [FreeBSD] (i386 FreeBSD/ELF) GNU C++ version 3.1.1 20020521 (prerelease) [FreeBSD] (i386-portbld-freebsd4.5) compiled by GNU C version 3.1.1 20020521 (prerelease) [FreeBSD]. #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1/include/g++ /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1/include/g++/i386-portbld-freebsd4.5 /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1/include/g++/backward /usr/local/include /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/include /usr/local/i386-portbld-freebsd4.5/include /usr/include End of search list. /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o conftest /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/crtbegin.o -L/usr/X11R6/lib -L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1 -L/usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/../../.. /var/tmp//ccLulSZf.o -lX11 -lstdc++ -lm -lgcc -lc -lgcc /usr/local/lib/gcc-lib/i386-portbld-freebsd4.5/3.1.1/crtend.o /usr/lib/crtn.o /var/tmp//ccLulSZf.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' GNU ld version 2.11.2 20010719 [FreeBSD] (with BFD 2.11.2 20010719 [FreeBSD]) Supported emulations: elf_i386 collect2: ld returned 1 exit status Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
On Wed, May 29, 2002 at 02:18:42PM +0400, Igor Roboul wrote: > > 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 function) > lib_gen.c:504: syntax error before numeric constant > lib_gen.c:504: syntax error before numeric constant This is problem with awk (nawk) which is used by MKlib_gen.sh After I had removed /usr/bin/awk and then have made link /usr/bin/awk -> /usr/bin/gawk libncurses have builded just fine -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT and P-IV problems
Hi all, I can tell now for sure, that all SIG11 and SIG4 problems are gone with make buildworld, if I compile here make(8) rm(8) mkdir(8) with -g -ggdb If I don't do that, make world stops after 4 - 30 seconds. So it could be definitly some optimizing bug in our gcc. And this bug seems to be present in gcc 2.95.4 as well, as in the new gcc 3.1. > The VAX and Windows debuggers are famous for making pointer > errors "disappear" when you compile /debug. GDB is better at > not doing this, but isn't perfect. Compiling with and without > debug will yield different code. > > -g makes binaries bigger, and prevents some optimizations, > even if you aren't telling the compiler to optimize. > > Does a "strip -g"'ed version of the -g compiled binary have the > same problem? No. This still works fine. I can compile with -g -ggdb and then strip the binary and it still works fine. > > Also, an "objdump -p" comparison of the two might be informative; > there were a number of problems in Alpha-land when the compiler > assumptions changed because of the new binutils. This might be a > similar problem to the ld.so problems there, only with the ELF > loader code. With -g -ggdb Program Header: LOAD off0x vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x0004e9ed memsz 0x0004e9ed flags r-x LOAD off0x0004ea00 vaddr 0x08097a00 paddr 0x08097a00 align 2**12 filesz 0x1598 memsz 0x00010d70 flags rw- NOTE off0x0094 vaddr 0x08048094 paddr 0x08048094 align 2**2 filesz 0x0018 memsz 0x0018 flags r-- The problematic version here on PIV 2Ghz: # objdump -p /bin/rm /bin/rm: file format elf32-i386 Program Header: LOAD off0x vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x0004e56d memsz 0x0004e56d flags r-x LOAD off0x0004e580 vaddr 0x08097580 paddr 0x08097580 align 2**12 filesz 0x1598 memsz 0x00010d70 flags rw- NOTE off0x0094 vaddr 0x08048094 paddr 0x08048094 align 2**2 filesz 0x0018 memsz 0x0018 flags r-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
Alfred Perlstein wrote: > * Peter Wemm <[EMAIL PROTECTED]> [020530 01:01] wrote: > > Wilko Bulte wrote: > > > 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 > > > > gcc-3.1 appears to have broken > > #pragma weak foo = bar > > What's the correct way to do this now? I dont know. :-( There are hacks that can work around it, but I think this is unintentional breakage. I tried changing this: #pragma weak foo = bar to __weak_reference(bar, foo); But I didn't get much further since Xfree86 was provoking internal compiler errors. Turning off -O entirely got around it a few times, and then I had more failures with lack of c++ libraries. The end result of all the futzing around ended up with a set of binaries that were basically hosed and usually segfaulted on startup. Shortly after that point, I then managed to panic my system (running 5.x) and said "to hell with it" and did a pkg_add -r to install it instead. I'm in the middle of moving, so I haven't had much more of a chance to look at it. There are GCC bugs involved. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
* Peter Wemm <[EMAIL PROTECTED]> [020530 01:01] wrote: > Wilko Bulte wrote: > > 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 > > gcc-3.1 appears to have broken > #pragma weak foo = bar What's the correct way to do this now? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4-libraries build error
Wilko Bulte wrote: > 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 gcc-3.1 appears to have broken #pragma weak foo = bar > 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 -f UIThrStubs.o > > LD_LIBRARY_PATH=../../exports/lib cc -c -O -pipe-ansi -pedantic > > -Dasm=__asm > > -Wall -Wpointer-arith -I../.. -I../../exports/include -DCSRG_BASED > > -DFUNC > > PROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API > > -DXNO_MTSAFE_PWDAPI-DM > > ALLOC_0_RETURNS_NULL-ansi -pedantic -Dasm=__asm -Wall > > -Wpointer-arith-I. > > ./.. -I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 > > -DNARROWPROTO -DXTHR > > EADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURNS_NULL > > -fPI > > C UIThrStubs.c > > UIThrStubs.c:102: alias arg not a string > > UIThrStubs.c:103: alias arg not a string > > UIThrStubs.c:104: alias arg not a string > > UIThrStubs.c:105: alias arg not a string > > UIThrStubs.c:106: alias arg not a string > > UIThrStubs.c:107: alias arg not a string > > UIThrStubs.c:108: alias arg not a string > > UIThrStubs.c:109: alias arg not a string > > UIThrStubs.c:110: alias arg not a string > > UIThrStubs.c:111: alias arg not a string > > UIThrStubs.c:113: alias arg not a string > > UIThrStubs.c:114: alias arg not a string > > UIThrStubs.c:115: alias arg not a string > > UIThrStubs.c:131: warning: `_Xthr_self_stub_' defined but not used > > UIThrStubs.c:139: warning: `_Xthr_zero_stub_' defined but not used > > *** Error code 1 > > > > Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/XThrStub. > > > > Pete... > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > ---end of quoted text--- > > -- > | / o / /_ _ [EMAIL PROTECTED] > |/|/ / / /( (_) Bulte Arnhem, the Netherlands > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII
Matthew Dillon wrote: > But that is not what is going on here. Not by a long shot. We have > people on this list that complain over the smallest 'infraction' of the > rules, and then jump up the alleged significance of the event by > foretelling gloom and doom and the end of all things if the rules are > not followed exactly to a T. > > It MUST STOP. It is not good for the development community or the > project. Rules are what seperate us from the apes. Apes with Internet access, degrees in CS, a working knowledge of CVS, an ability to code, mailing list access, and commit bits. Oh wait. That was "the ability to grow UNIX guru beards" that seperated us from the apes. Never mind... -- I can see both sides of the argument. I've seen the "please make style commits seperately" argument used to squelch style changes, which are nearly impossible to justify on their own. I've also seen style changes go in with other changes, and the style changes just ended up being gratuitous diffs against the other BSD's, and made it harder to share code. Mostly, I dislike both points: the first is to prevent necessary change, and the second might be attributable to laziness. I've personally posted patches that inverted the logic of functions, which people have claimed were style changes. I guess they were, until you later go in and add the asserts on entry/exit lock state, etc.. -- Julian's penchant for putting squiggly braces around single statements is something I ran into when working with him at Whistle. Frankly, it doesn't bother me one way or the other. It's mostly useless (IMO), but it makes it easier to put in debugging statements that don't end up changing logic (Julian's initial argument to me; I like putting adjunct squigglies in the first column with the debugging statements themselves, personally). As gratuitous diffs go, these are incredibly minor. I think most gratuitous diffs disappear anyway, when you make "diff" ignore whitespace. Most complaints work out to be an inability on the part of the maintainer to work "diff", and whining that because they can't work the back end of the hammer, no one should use the front end of one to pound in nails, because they would be unable to pull them out later wigth their own hammers. My answer to that is "a craftsman knows his tools". Hell, if it makes things easier for Julian to put in more code, then it's OK with me. He's done the lion's share of work on getting KSE into FreeBSD so far (IMO). That's my opinion, FWIW. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lose 14 Pounds In 14 Days 9480
Hey there, If you're like me, you've tried EVERYTHING to lose weight. I know how you feel - the special diets, miracle pills, and fancy exercise equipment never helped me lose a pound either. It seemed like the harder I tried, the bigger I got, until I heard about a product called Extreme Power Plus. You're probably thinking to yourself, "Oh geez, not another miracle diet pill!" Like you, I was skeptical at first, but my sister swore it helped her lose 23 pounds in just two weeks, so I told her I'd give it a shot. I mean, there was nothing to lose except a lot of weight! Let me tell you, it was the best decision I've ever made. Period. Six months later, as I'm writing this message to you, I've gone from 355 pounds to 210 pounds, and I haven't changed my exercise routine or diet at all. Yes, I still eat pizza, and lots of it! I was so happy with the results that I contacted the manufacturer and got permission to resell it - at a BIG discount. I want to help other people lose weight like I did, because it does so much for your self-esteem, not to mention your health. I give you my personal pledge that Extreme Power Plus absolutely WILL WORK FOR YOU. If it doesn't, you can return it any time for a full refund. If you are frustrated with trying other products, not having any success, and just not getting the results you were promised, then I recommend the only product that worked for me - EXTREME POWER PLUS. You're probably asking yourself, "Ok, so how does this stuff actually work?" Extreme Power Plus contains Lipotropic fat burners and ephedra which is scientifically proven to increase metabolism and cause rapid weight loss. No "hocus pocus" in these pills - just RESULTS, RESULTS, RESULTS!! Here is the bottom line ... I can help you lose 10-15 pounds per week naturally, without exercising and without having to eat rice cakes all day. Just try it for one month - there's nothing to lose, and everything to gain. You will lose weight fast - GUARANTEED. That is my pledge to you. To order Extreme Power Plus on our secure server, just click on the link below: http://www.2002marketing.com/power/extreme.cfm If you have difficulty accessing the website above, please try our mirror site by clicking on the link below: http://www.2002marketing.com/power/extreme.cfm To see what some of our customers have said about this product, visit http://www.2002marketing.com/power/extreme.cfm To see a list of ingredients and for more information on test studies and how it will help you lose weight, visit http://www.2002marketing.com/power/extreme.cfm * If you do not wish to receive any more emails from me, please send an email to "[EMAIL PROTECTED]" requesting to be removed. * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
