Re: rsync 5.x breakage

* David O'Brien [EMAIL PROTECTED] [2002-06-18 05:32]: On Sun, Jun 16, 2002 at 02:30:29PM +0200, Oliver Braun wrote: The problem is that sed(1) on -current fails with sed -i.bak file, if file.bak already exists, but perl does not. Please file a PR about this. done Since

Re: PATCH: wchar_t is already defined in libstd++

On 17 Jun, David O'Brien wrote: Actually, the correct approach would be to avoid defining _BSD_WCHAR_T_ when compiling C++. This way, it only needs to be done I am much more likely to force the libstdc++ build to use our _BSD_WCHAR_T_. Our types should be centralized and not in some

Re: PATCH: wchar_t is already defined in libstd++

Hi Terry, Terry Lambert wrote: In any case, here is a patch for i386; you will need similar patches for the other architectures. Oops. I messed the negative logic. BTW, that should be an #ifndef insdtead of a #ifdef in your original patch. Here is a corrected patch for ansi.h.

Re: PATCH: wchar_t is already defined in libstd++

Martin Blapp wrote: This looks ok to me. And like this we would only have to change one file, Garrett is right. That's the first thing I said: Garrett's right. David O'Brian had the point that there was a tools dependency that this imposes that maybe ought not to be there. Since wchar_t is a

Re: PATCH: wchar_t is already defined in libstd++

David O'Brien [EMAIL PROTECTED] wrote: On Mon, Jun 17, 2002 at 06:16:45PM -0400, Garrett Wollman wrote: On Mon, 17 Jun 2002 18:02:17 -0400 (EDT), Thomas David Rivers [EMAIL PROTECTED] said: The correct approach (and, I have to admit to not glancing at your patch) would be:

Re: PATCH: wchar_t is already defined in libstd++

Thomas David Rivers wrote: Personally, I vote for u_int16_t... Unicode 16 bit, vs. ISO-10646 code page zero (other code pages aren't defined at all anyway, and it matches Windows, in case you want to use an ELF library from a Windows box, if you can figure out how). I noticed before

buildworld failed

Hello, I have got following error while building today's -CURRENT: === usr.bin/truss cp /opt/freebsd-current/src/usr.bin/truss/../../sys/kern/syscalls.master syscall s.master /bin/sh /opt/freebsd-current/src/usr.bin/truss/../../sys/kern/makesyscalls.sh sy scalls.master

Re: buildworld failed

On 2002.06.18 16:44:01 +, Igor Roboul wrote: Hello, I have got following error while building today's -CURRENT: if you'd bothered to read the mailing lists a little bit more closely you'd know that by now this issue has been discussied in at least 2 threads already, latest one being only

Re: buildworld failed

gmh003532 the fix is (yet again) to rebuild sed. Is this mean that src/usr.bin/sed should be a build-tool? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message

Kernel Build Fails - Syscons errors...

While compiling a new kernel based on today's sources, I get the following errors from the syscons history code: [freya] [/sys/i386/compile/freya5] # make cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual

Re: rsync 5.x breakage

On Tue, Jun 18, 2002 at 10:21:32AM +0200, Oliver Braun wrote: BTW, why have you added BUILD_DEPENDS= perl:${PORTSDIR}/lang/perl5 to net/rsync? Only for the patches? Correct, for the use of perl -pi -e. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the

Re: buildworld failed

On Wed, Jun 19, 2002 at 12:05:00AM +0900, Makoto Matsushita wrote: gmh003532 the fix is (yet again) to rebuild sed. Is this mean that src/usr.bin/sed should be a build-tool? No, there was a bad commit to sed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current

Suggested fixes for uidinfo would sleep messages

As with others on the list, I've been getting a lot of witness complaints: ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:511 ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:613 Basically, every

Re: Suggested fixes for uidinfo would sleep messages

* Nate Lawson [EMAIL PROTECTED] [020618 12:17] wrote: As with others on the list, I've been getting a lot of witness complaints: ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:511 ../../../vm/uma_core.c:1327: could sleep with process lock

Re: C++ problems

On Sun, Jun 16, 2002 at 07:31:56AM +0200, Michael Nottebrock wrote: I just hit the same problem while trying to compile KDE stuff. In my case it stems from bsd.kde.mk adding -I/usr/include to CPPFLAGS Why in the (*_#$ did someone make bsd.kde.mk do that?? To Unsubscribe: send mail to [EMAIL

Re: C++ problems

In the last episode (Jun 18), David O'Brien said: On Sun, Jun 16, 2002 at 07:31:56AM +0200, Michael Nottebrock wrote: I just hit the same problem while trying to compile KDE stuff. In my case it stems from bsd.kde.mk adding -I/usr/include to CPPFLAGS Why in the (*_#$ did someone make

Re: PATCH: wchar_t is already defined in libstd++

On Tue, Jun 18, 2002 at 04:46:32AM -0700, Terry Lambert wrote: : My ulterior motives are: : o Complete disdain for ISO-10646 being 32 bits, when 16 : of them are never anything but 0, and were put there just : so that people could grep -v other people's languages out : of

RE: PATCH: wchar_t is already defined in libstd++

Title: RE: PATCH: wchar_t is already defined in libstd++ Hi Terry and all, I usually just lurk on the list, but since I'm a C++ afficionado, I wanted to question your below snipped statement. If we settle on wchar_t being 16bits, then we will still be forced to do UTF-7/8/16 to properly

Re: PATCH: wchar_t is already defined in libstd++

Peter S. Housel wrote: o Complete disdain for ISO-10646 being 32 bits, when 16 of them are never anything but 0, and were put there just so that people could grep -v other people's languages out of documents o I'll believe Hieroglyphics and Linear B when I see the fonts and the

C++ troubles continue

Trying to build kdebase3 on the FreeBSD 5.0-CURRENT #7: Mon Jun 17 22:46:16 EDT 2002 [...] gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder/apps' gmake[3]: Leaving directory

$B!{9-9p!{!!@GL3!&2q7W!&7PM}!&5-D"(B$B$J$I$G$*G:$_$G$7$?$i!&!&!&(B

$B#P#R(B- $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B"#7PM}!&7h;;!&3NDj?=9p!&2q

i386 tinderbox failure

-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree

new zero copy sockets snapshot

I've released a new zero copy sockets snapshot, against -current from June 18th, 2002. http://people.FreeBSD.org/~ken/zero_copy The fixes that went into this snapshot: - Take mutex locking out of ti_attach(), it isn't really needed. As long as we can assume that probes of successive ti(4)

Re: new zero copy sockets snapshot

On Tue, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote: I've released a new zero copy sockets snapshot, against -current from June 18th, 2002. http://people.FreeBSD.org/~ken/zero_copy The fixes that went into this snapshot: - Take mutex locking out of ti_attach(), it

Re: new zero copy sockets snapshot

On Wed, Jun 19, 2002 at 00:43:13 -0400, Bosko Milekic wrote: On Tue, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote: I've released a new zero copy sockets snapshot, against -current from June 18th, 2002. http://people.FreeBSD.org/~ken/zero_copy The fixes that went into

Re: Suggested fixes for uidinfo would sleep messages

On 18 Jun, Alfred Perlstein wrote: * Nate Lawson [EMAIL PROTECTED] [020618 12:17] wrote: As with others on the list, I've been getting a lot of witness complaints: ../../../vm/uma_core.c:1327: could sleep with process lock locked from ../../../kern/kern_prot.c:511

Re: C++ troubles continue

Charlie Root wrote: Trying to build kdebase3 on the FreeBSD 5.0-CURRENT #7: Mon Jun 17 22:46:16 EDT 2002 [...] gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder/apps' gmake[3]: Leaving directory