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 net/rsync/Makefile
> > uses 3 ${REINPLACE_CMD}s on one file (rsync.h), I have removed the
> > backup file with ${RM} file.bak between the calls.
> :-( I can see I should not have dropped maintainership of this port.
The 3 substitutions on one file were already present when I take over
maintainership.
As I have written before I am not very happy with my fix. So, if you
have a better solution, please let me know.
BTW, why have you added BUILD_DEPENDS= perl:${PORTSDIR}/lang/perl5 to
net/rsync? Only for the patches?
Regards,
Olli
--
IST & IIS _ INF _ UniBwM ___ http://ist.unibw-muenchen.de/People/obraun/
Tele-Consulting GmbH ___ http://www.tele-consulting.com/ ___ obraun@
FreeBSD: The Power To Serve http://www.freebsd.org/ ___
GnuPG: 0xEF25B1BA Fingerprint: 6A3B 042A 732E 17E4 B6E7 3EAF C0B1 6B7D EF25 B1BA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 hidden > vendor software that often makes wrong assumptions about us. This breaks other compilers. In my tree I have a patch which looks like Martin's first patch to fix the same problem with icc. Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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. This looks ok to me. And like this we would only have to change one file, Garrett is right. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 reserved keyword in C++ according to the standard, I think that the synchronization of the size of the object when it's typedef'ed matching the size of the object manifest in C++, is FreeBSD's problem (hence my earlier comment about being screwed based on the wchar_t size). It's annoying, but it's something that the OS pretty much has to eat. The only workaround might be to size the type with config code in C++ to generate the header from a template (I don't like that). 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). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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:
> > <<[EMAIL PROTECTED]> said:
> >
> > > The correct approach (and, I have to admit to not
> > > glancing at your patch) would be:
> >
> > >#ifndef __cplusplus
> > >typedef _BSD_WCHAR_T_ wchar_t
> > >#endif
> >
> > 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 hidden
> vendor software that often makes wrong assumptions about us.
I accidently sent a reply to just David, so please forgive
the duplicate.
I think there is a misunderstanding here...
It's not that the vendor software has "hidden" the definition
of `wchar_t'. The C++ standard mandates that `wchar_t' be
a "builtin" type, just like `int'.
This is so function overloading can distinguish based on the
`wchar_t' type.
That is, these would be two *different* functions in a standard-
conforming implementation:
void
foo(unsigned int)
{
}
void
foo(wchar_t)
{
}
If `wchar_t' is simply a typedef provided by the headers,
then the implementation isn't C++ standard conforming.
Also note that the source above is C++ standard conforming,
you don't need to #include anything to get the definition
of `wchar_t'.
gcc v3.x finally gets this correct - and we have to adjust
the headers to no longer define a typedef for wchar_t
in this situation.
This is not a situation of gcc being wrong - it's the
opposite - gcc is getting closer to right :-)
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: wchar_t is already defined in libstd++
Terry Lambert <[EMAIL PROTECTED]> wrote: > > 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 > reserved keyword in C++ according to the standard, I think that the > synchronization of the size of the object when it's typedef'ed > matching the size of the object manifest in C++, is FreeBSD's > problem (hence my earlier comment about being screwed based on the > wchar_t size). It's annoying, but it's something that the OS > pretty much has to eat. The only workaround might be to size the > type with config code in C++ to generate the header from a template > (I don't like that). > > 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 that you mentioned you didn't want the wchar_t to be int-sized (i.e. 32 bits.) I was just wondering why. If we "shrink" the size at this point, would that have some impact on existing programs. (Currently, the typedef for `wchar_t' works down to an `int', if I'm not mistaken.) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 that you mentioned you didn't want the > wchar_t to be int-sized (i.e. 32 bits.) I was just wondering > why. > > If we "shrink" the size at this point, would that have some > impact on existing programs. (Currently, the typedef > for `wchar_t' works down to an `int', if I'm not mistaken.) My ulterior motives are: o Sloppily written code, ported from other platforms o Compatability with Windows (e.g. NTFS, VFAT32FS) 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 programs that use them. Dead languages pretty much justify purpose-built linguistics software anyway. o A desire for raw storage of Unicode, rather than UTF-8 or UTF-7 encoding. This last one is: o UTF encoding is mostly so people using US-ASCII don't have to change their data (and to hell with the rest of the world). ASCII centrism is why we're having to invent a new type today. o UTF encoding breaks fixed field storage, which has always bean a measure of the number of characters you can put in a field. o UTF encoding breaks the historical (and really nice) "size_of_file/sizeof(struct) := number_of_records" o Not knowing if a character will take 1 byte or 5 bytes means that your fixed length input fields in browsers have to be fixed at 1/5th the number of characters as bytes available to store the input result o People might accept doubling data size for the benefit of internationalization. They aren't going to accept a random multiplier between 1 and 5. o Storage encoding and processing encoding should be the same thing, and not require conversion (yeah, I know, I was there for the comp.std.internat arguments with Ohta-san about hating Unicode because it didn't use EUC encoding, used Chinese dictionary ordering, and wan't "JIS-208 + extensions"; frankly, I think most Japanese don't care, as long as it works, which is why Windows hasn't suffered sales losses). I really, really hate doing field length conversions in code; I rather suspect it will lead to as many bugs as NUL terminated strings and "strcpy()" and "sprintf()" have led to buffer overflows. More justification than I intended, but I think the GCC default on most platforms was chosen to *intentionally* be incompatible with Windows. The decision should be made on technical merits, rather than blind hatred. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 /opt/freebsd-current/src/usr.bin/truss/i386.conf syscalls.master: line 55: syscall number out of sync at 7 line is: struct rusage * rusage ) ; } wait4 wait_args int -- 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: 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 a day old. the fix is (yet again) to rebuild sed. > ===> 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 /opt/freebsd-current/src/usr.bin/truss/i386.conf > syscalls.master: line 55: syscall number out of sync at 7 > line is: > struct rusage * rusage ) ; } wait4 > wait_args int To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 -Wno-format -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/syscons/schistory.c ../../../dev/syscons/schistory.c: In function `sc_alloc_history_buffer': ../../../dev/syscons/schistory.c:127: void value not ignored as it ought to be ../../../dev/syscons/schistory.c:127: syntax error before ')' token ../../../dev/syscons/schistory.c: In function `sc_hist_ioctl': ../../../dev/syscons/schistory.c:306: void value not ignored as it ought to be ../../../dev/syscons/schistory.c:306: syntax error before ')' token *** Error code 1 Stop in /usr/src/sys/i386/compile/freya5. TIA for assistance... /robert/ -- --- END --- "At a dinner party one should eat wisely but not too well, and talk well but not too wisely." -- W. Somerset Maugham (1874-1965) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 body of the message
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" in the body of the message
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 time cron runs, it does a setuid() or seteuid(), which calls change_ruid or change_euid which call uifree and uifind (which does the malloc with M_WAITOK while holding PROC_LOCK). kern/kern_resource.c:862 uifind() attempts to avoid sleeping with the hash table mutex by unlocking it, mallocing a new uidinfo, then locking it again and checking that another thread didn't create the same uidinfo while it was asleep. However, there may be other locks held at the same time (namely, PROC_LOCK) that uifind is not aware of. Here are a couple of suggested fixes: 1. Break uifind back into uifind, uicreate, and uiinsert. If uifind returns NULL, caller drops all locks, calls uicreate, grabs locks, checks uifind again, and calls uiinsert. 2. Split set*uid execution into lookup, (optionally) create, and modify phases. Locks only need to be held for lookup and modify. Is anyone else working on a fix? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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" locked from > ../../../kern/kern_prot.c:613 > > Basically, every time cron runs, it does a setuid() or seteuid(), which > calls change_ruid or change_euid which call uifree and uifind (which does > the malloc with M_WAITOK while holding PROC_LOCK). ... > Is anyone else working on a fix? The code should not be holding proc locks over ui*() calls. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 bsd.kde.mk do that??
It was an attempt to work around a bug in the pth port. The pth bug
was fixed in
RCS file: /home/ncvs/ports/devel/pth/pkg-plist,v
revision 1.11
date: 2001/09/11 14:49:45; author: sf; state: Exp; lines: +10 -8
install headers/libraries under its own directory, ${PREFIX}/includes/pth and
${PREFIX}/lib/pth, to avoid conflict with FreeBSD pthread.
.. but bsd.kde.mk was not fixed until yesterday (and the PR on it is
still open: ports/37681 it can be closed now).
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 documents Actually it's 21 bits, and there are already some characters defined above 0x. -- Christopher Vance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 handle a random Unicode (or ISO/IEC 10646) string, since we must deal with that charming thing known as "surrogate pairs" (see section 3.7 of the Unicode standard v3.0). This again breaks the "one wchar_t == on character". When being forced to deal with Unicode, I much prefer working with 32bits, since that guarantees that I get a fixed length for each character. Admittedly, it is space inefficient to the Nth degree, but speedwise it is better. As for interoperability with Windows, it is clearly stated that the wchar_t is intended for internal usage only, and the various encoding schemes should be used when storing strings outside of a process. In reality this means that just about every Unicode capable application reads and writes in UTF-8 or 7. This means that interoperability should not become an issue. If it really was expected to have been an issue, I'm sure the C++ standard would have mandated a specific width for wchar_t, which as far as I am aware they didn't. The draft copy I pulled out via google says the following: Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest extended character set specified among the supported locales (_lib.locale_). Type wchar_t shall have the same size, signedness, and alignment requirements (_intro.memory_) as one of the other integral types, called its underlying type. So, in the light of this, what would be the most appropriate choice? I haven't yet had a chance to explore what locales we support, but I would lean toward saying wchar_t == 32 bits, since this is future proof. If we later down the track are forced to go from 16 -> 32 due us supporting more of the asian locales, I foresee this causing _major_ breakage. If anyone actually has a copy of the C++ standard and would be kind enough to paste the section regarding the size of wchar_t, that would be most helpful for this discussion I believe. Regards, /Johny -- Johny Mattsson | Email: [EMAIL PROTECTED] Ericsson Support Engineer | Phone: +61 (0)3 9301 1372 NCSA NetScreen Certified | Mobile: +61 (0)404 003 713 -Original Message- From: Terry Lambert [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 9:47 PM To: Thomas David Rivers Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PATCH: wchar_t is already defined in libstd++ o A desire for raw storage of Unicode, rather than UTF-8 or UTF-7 encoding. This last one is: o UTF encoding breaks fixed field storage, which has always bean a measure of the number of characters you can put in a field.
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 programs that use them. Dead languages > > pretty much justify purpose-built linguistics software > > anyway. > > If you were a MathML user, or had a Chinese name using an obscure character, > you would probably feel differently. Why? Have the Chinese sent representatives to an international standards body to get code pages other than 0 filled in with these characters? Have the MathML users? Basically, it's not necessary to have bits to represent these code points until they are parts of a standard character set. The entire point of Unicode was to provide round-trip capability between character sets. For MathML, you can actually unify the code points with Zapf or other characters thatdon't exist simultaneously in any character sets. Alrternately, you could use a "private use" area. > > o A desire for raw storage of Unicode, rather than UTF-8 or > > UTF-7 encoding. This last one is: > > You still need at least 21 bits to have "raw storage of Unicode". With > anything less, either UTF-16 surrogates or UTF-8 multi-byte encodings have > to be used. With a 16-bit wchar_t, even if I personally don't have any text > that uses characters beyond the BMP, I still have to write my code to > account for surrogates. Unicode 3.2.0 is not an ISO/IEC standard. It's a political thing. You might have an argument for ISO-10646-2:2001; however "Klingon" is not a script I'm really worried about. 8-). > > o People might accept doubling data size for the benefit > > of internationalization. They aren't going to accept > > a random multiplier between 1 and 5. > > I suspect UTF-16 doesn't compress very well using standard tools, and it is > subject to byte-order difficulties. (That goes double for UTF-32, of > course.) wchar_t probably shouldn't be directly used for storage. Anything larger than a byte has byte order problems; that was one of the original rationales for UTF-8 encoding. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder/apps' gmake[3]: Entering directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder' /bin/sh ../libtool --mode=link --tag=CXX c++ -DNDEBUG -DNO_DEBUG -O2 -O -march=i686 -pipe -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST-o kappfinder -L/opt/lib -pthread -L/opt/lib -R /opt/lib -R /opt/lib -R /opt/lib -R /opt/lib main.o scanner.o checker.o kappfinder_meta_unload.o -lkdeui c++ -DNDEBUG -DNO_DEBUG -O2 -O -march=i686 -pipe -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o kappfinder -pthread main.o scanner.o checker.o kappfinder_meta_unload.o -L/opt/lib /opt/lib/libkdeui.so /opt/lib/libkdecore.so -L/usr/lib /opt/lib/libDCOP.so /opt/lib/libkdefx.so -lqt-mt -lpng -lz -lXext -lX11 -lSM -lICE -lXrender -lstdc++ -lm -lgcc -Wl,--rpath -Wl,/opt/lib -Wl,--rpath -Wl,/opt/lib checker.o: In function `checkDesktopFile(QString const&, QString)': checker.o(.text+0x536): undefined reference to `cout' checker.o(.text+0x543): undefined reference to `ostream::operator<<(char const*)' checker.o(.text+0x575): undefined reference to `ostream::operator<<(char const*)' checker.o(.text+0x585): undefined reference to `ostream::operator<<(char const*)' checker.o(.text+0x6f1): undefined reference to `cout' checker.o(.text+0x6fe): undefined reference to `ostream::operator<<(char const*)' checker.o(.text+0x706): undefined reference to `endl(ostream&)' checker.o(.text+0x7e1): undefined reference to `cout' checker.o(.text+0x7ea): undefined reference to `ostream::operator<<(char const*)' checker.o(.text+0x7f2): undefined reference to `endl(ostream&)' gmake[3]: *** [kappfinder] Error 1 gmake[3]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1' gmake: *** [all] Error 2 *** Error code 2 Any clues? The /usr/lib/libstdc++.a has, for example: W std::basic_ostream >& std::endl >(std::basic_ostream >&) B std::cout B std::buf_cout U std::cout U std::buf_cout -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
freebsd-current@freebsd.org
$B#P#R(B- $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B"#7PM}!&7h;;!&3NDj?=9p!&2qhttp://expert-net.com/samurai/sakino/ $B$r1?1D!&4IM}$7$F$$$^$9@hLn$H$^$9!#(B $B$b$7!"3NDj?=9p$d=q$-J}!&7h;;!&7PM}$J$I$G$*G:$_$G$7$?$i!"(B $B$<$REv%5%$%H$r$4MxMQ$7$F$_$F$/$@$5$$!#(B $BEv%5%$%H$G$OA49q#1#0#0#0L>0J>e$N;N6H@h@8$,(B $B$4EPO?$7$FD:$$$F$$$^$9!JEl5~ETFb$G$O(B400$BL>0J>e!K(B $B$b$A$m$s8f8+@Q$OA49q$GC5$;$F0l3gL5NA8+@Q$G$9(B $B!JEv%5%$%H$O;N6H@h@8$+$i$N1?1DHq$G1?1D$7$F$*$j$^$9!K(B $BA49q$GC5$;$F0l3g$GL5NA8+@Q$G$9!#(B $B$b$C$H6a$/$F!"0B$/$F!"G/Np$G!"?'!9$J@h@8$rA*$Y$F0B?4!#(B $B7PM}!"7h;;!"?=9p!"8\Ld!"AjB3@G!"5/6H;Y1g!"7PM}Be9T!"5kM?7W;;!"(B $B2qhttp://expert-net.com/samurai/sakino/ $B"#L5NA8+@Q0l3g?=@A%U%)!<%`"#(B http://expert-net.com/samurai/sakino/estimateform.html -- $B"(%a!<%k%"%I%l%9$OBgJQ62$l$J$,$i!"%M%C%H>e$G$*D4$Y$5$;$FD:$-$^$7$?!#(B $B!!@?$K62$lF~$j$^$9$,!"$4ITMW$G$"$l$P$4>C5n!"(B $B$^$?$OJV?.$7$F$/$@$5$$$^$9$h$&$*4j$$?=$7>e$2$^$9!#(B // $BM-8B2qhttp://expert-net.com/samurai/sakino/ // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 >/home/des/tinderbox/i386/obj/local0/scratch/tinderbox/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> gnu/lib/libreadline ===> gnu/lib/libreadline/history ===> gnu/lib/libreadline/history/doc /local0/scratch/tinderbox/src/gnu/lib/libreadline/history/doc/../../../../../contrib/libreadline/doc/hstech.texinfo:451: warning: unlikely character [ in @var. /local0/scratch/tinderbox/src/gnu/lib/libreadline/history/doc/../../../../../contrib/libreadline/doc/hstech.texinfo:451: warning: unlikely character ] in @var. ===> gnu/lib/libreadline/readline ===> gnu/lib/libreadline/readline/doc ===> gnu/lib/libstdc++ ===> gnu/lib/libstdc++/doc make: don't know how to make iostream.info. Stop *** Error code 2 Stop in /local0/scratch/tinderbox/src/gnu/lib/libstdc++. *** Error code 1 Stop in /local0/scratch/tinderbox/src/gnu/lib. *** Error code 1 Stop in /local0/scratch/tinderbox/src/gnu. *** Error code 1 Stop in /local0/scratch/tinderbox/src. *** Error code 1 Stop in /local0/scratch/tinderbox/src. *** Error code 1 Stop in /local0/scratch/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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) instances happen sequentially, we'll be safe in doing this. Thanks to John Baldwin for pointing out the solution to that problem. (The lock in ti_attach() was causing all sorts of WITNESS warnings when bus_setup_intr() was called.) - Added a new routine, vm_object_allocate_wait(). This is a variant of vm_object_allocate() that allows the user to specify whether the uma_zalloc() call inside vm_object_allocate_wait() is called with M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and potentially gives other callers the option of eliminating the mandatory wait on the uma_zalloc() call. (vm_object_allocate() now just calls vm_object_allocate_wait() with the proper argument.) With those fixes, plus several fixes that have gone into -current over the past week or so, the zero copy sockets code runs without any WITNESS warnings at all now. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 isn't really needed. >As long as we can assume that probes of successive ti(4) instances >happen sequentially, we'll be safe in doing this. Thanks to John >Baldwin for pointing out the solution to that problem. (The lock in >ti_attach() was causing all sorts of WITNESS warnings when >bus_setup_intr() was called.) > > - Added a new routine, vm_object_allocate_wait(). This is a variant of >vm_object_allocate() that allows the user to specify whether the >uma_zalloc() call inside vm_object_allocate_wait() is called with >M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when >jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and >potentially gives other callers the option of eliminating the mandatory >wait on the uma_zalloc() call. I think this problem was fixed in recent -CURRENT by JeffR. Notably, the VM system should not allow itself to recurse on itself when called with M_NOWAIT. >(vm_object_allocate() now just calls vm_object_allocate_wait() with the >proper argument.) > > With those fixes, plus several fixes that have gone into -current over the > past week or so, the zero copy sockets code runs without any WITNESS > warnings at all now. > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 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) instances
> >happen sequentially, we'll be safe in doing this. Thanks to John
> >Baldwin for pointing out the solution to that problem. (The lock in
> >ti_attach() was causing all sorts of WITNESS warnings when
> >bus_setup_intr() was called.)
> >
> > - Added a new routine, vm_object_allocate_wait(). This is a variant of
> >vm_object_allocate() that allows the user to specify whether the
> >uma_zalloc() call inside vm_object_allocate_wait() is called with
> >M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when
> >jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and
> >potentially gives other callers the option of eliminating the mandatory
> >wait on the uma_zalloc() call.
>
> I think this problem was fixed in recent -CURRENT by JeffR. Notably,
> the VM system should not allow itself to recurse on itself when called
> with M_NOWAIT.
A number of problems have been fixed, but I don't think this one would get
fixed by internal VM system changes:
vm_object_t
vm_object_allocate(objtype_t type, vm_size_t size)
{
vm_object_t result;
result = (vm_object_t) uma_zalloc(obj_zone, M_WAITOK);
_vm_object_allocate(type, size, result);
return (result);
}
uma_zalloc() is called with M_WAITOK unconditionally.
My solution:
vm_object_t
vm_object_allocate_wait(objtype_t type, vm_size_t size, int flags)
{
vm_object_t result;
result = (vm_object_t) uma_zalloc(obj_zone, flags);
if (result != NULL)
_vm_object_allocate(type, size, result);
return (result);
}
vm_object_allocate() is implemented by calling vm_object_allocate_wait()
with M_WAITOK.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
>> ../../../vm/uma_core.c:1327: could sleep with "process lock" locked from
>> ../../../kern/kern_prot.c:613
>>
>> Basically, every time cron runs, it does a setuid() or seteuid(), which
>> calls change_ruid or change_euid which call uifree and uifind (which does
>> the malloc with M_WAITOK while holding PROC_LOCK).
> ...
>> Is anyone else working on a fix?
>
> The code should not be holding proc locks over ui*() calls.
I finally got tired of seeing these messages. Since I haven't seen
anybody post a patch, I bit the bullet and cranked one out. It could
use some examination to make sure that the reference counts are handled
properly and there aren't any leaks. I'm not terribly happy about
having to unhide the uidinfo stuff and expose it to the users of
change_{r,e}uid(), and I don't like allocating memory before checking
permissions, but it looks like the alternatives are worse.
Index: sys/alpha/osf1/osf1_misc.c
===
RCS file: /home/ncvs/src/sys/alpha/osf1/osf1_misc.c,v
retrieving revision 1.30
diff -u -r1.30 osf1_misc.c
--- sys/alpha/osf1/osf1_misc.c 13 Apr 2002 23:11:22 - 1.30
+++ sys/alpha/osf1/osf1_misc.c 18 Jun 2002 19:11:50 -
@@ -1056,17 +1056,20 @@
struct proc *p;
int error;
uid_t uid;
+ struct uidinfo *uip;
struct ucred *newcred, *oldcred;
p = td->td_proc;
uid = SCARG(uap, uid);
newcred = crget();
+ uip = uifind(uid);
PROC_LOCK(p);
oldcred = p->p_ucred;
if ((error = suser_cred(p->p_ucred, PRISON_ROOT)) != 0 &&
uid != oldcred->cr_ruid && uid != oldcred->cr_svuid) {
PROC_UNLOCK(p);
+ uifree(uip);
crfree(newcred);
return (error);
}
@@ -1074,7 +1077,7 @@
crcopy(newcred, oldcred);
if (error == 0) {
if (uid != oldcred->cr_ruid) {
- change_ruid(newcred, uid);
+ change_ruid(newcred, uip);
setsugid(p);
}
if (oldcred->cr_svuid != uid) {
@@ -1083,11 +1086,12 @@
}
}
if (newcred->cr_uid != uid) {
- change_euid(newcred, uid);
+ change_euid(newcred, uip);
setsugid(p);
}
p->p_ucred = newcred;
PROC_UNLOCK(p);
+ uifree(uip);
crfree(oldcred);
return (0);
}
Index: sys/kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.164
diff -u -r1.164 kern_exec.c
--- sys/kern/kern_exec.c7 Jun 2002 05:41:27 - 1.164
+++ sys/kern/kern_exec.c18 Jun 2002 19:09:06 -
@@ -128,6 +128,7 @@
struct proc *p = td->td_proc;
struct nameidata nd, *ndp;
struct ucred *newcred = NULL, *oldcred;
+ struct uidinfo *euip;
register_t *stack_base;
int error, len, i;
struct image_params image_params, *imgp;
@@ -303,6 +304,7 @@
* Malloc things before we need locks.
*/
newcred = crget();
+ euip = uifind(attr.va_uid);
i = imgp->endargs - imgp->stringbase;
if (ps_arg_cache_limit >= i + sizeof(struct pargs))
newargs = pargs_alloc(i);
@@ -390,7 +392,7 @@
*/
crcopy(newcred, oldcred);
if (attr.va_mode & VSUID)
- change_euid(newcred, attr.va_uid);
+ change_euid(newcred, euip);
if (attr.va_mode & VSGID)
change_egid(newcred, attr.va_gid);
setugidsafety(td);
@@ -472,6 +474,7 @@
/*
* Free any resources malloc'd earlier that we didn't use.
*/
+ uifree(euip);
if (newcred == NULL)
crfree(oldcred);
else
Index: sys/kern/kern_prot.c
===
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.156
diff -u -r1.156 kern_prot.c
--- sys/kern/kern_prot.c19 May 2002 00:14:48 - 1.156
+++ sys/kern/kern_prot.c18 Jun 2002 18:50:01 -
@@ -503,11 +503,13 @@
struct proc *p = td->td_proc;
struct ucred *newcred, *oldcred;
uid_t uid;
+ struct uidinfo *uip;
int error;
mtx_lock(&Giant);
uid = uap->uid;
newcred = crget();
+ uip = uifind(uid);
PROC_LOCK(p);
oldcred = p->p_ucred;
@@ -537,11 +539,15 @@
#endif
(error = suser_cred(oldcred, PRISON_ROOT)) !
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
>`/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder/apps'
> gmake[3]: Entering directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder'
> /bin/sh ../libtool --mode=link --tag=CXX c++ -DNDEBUG -DNO_DEBUG -O2 -O -march=i686
>-pipe -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT
>-DQT_NO_ASCII_CAST-o kappfinder -L/opt/lib -pthread -L/opt/lib -R /opt/lib -R
>/opt/lib -R /opt/lib -R /opt/lib main.o scanner.o checker.o kappfinder_meta_unload.o
>-lkdeui
> c++ -DNDEBUG -DNO_DEBUG -O2 -O -march=i686 -pipe -fno-exceptions -fno-check-new
>-DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o kappfinder -pthread main.o
>scanner.o checker.o kappfinder_meta_unload.o -L/opt/lib /opt/lib/libkdeui.so
>/opt/lib/libkdecore.so -L/usr/lib /opt/lib/libDCOP.so /opt/lib/libkdefx.so -lqt-mt
>-lpng -lz -lXext -lX11 -lSM -lICE -lXrender -lstdc++ -lm -lgcc -Wl,--rpath
>-Wl,/opt/lib -Wl,--rpath -Wl,/opt/lib
> checker.o: In function `checkDesktopFile(QString const&, QString)':
> checker.o(.text+0x536): undefined reference to `cout'
> checker.o(.text+0x543): undefined reference to `ostream::operator<<(char const*)'
> checker.o(.text+0x575): undefined reference to `ostream::operator<<(char const*)'
> checker.o(.text+0x585): undefined reference to `ostream::operator<<(char const*)'
> checker.o(.text+0x6f1): undefined reference to `cout'
> checker.o(.text+0x6fe): undefined reference to `ostream::operator<<(char const*)'
> checker.o(.text+0x706): undefined reference to `endl(ostream&)'
> checker.o(.text+0x7e1): undefined reference to `cout'
> checker.o(.text+0x7ea): undefined reference to `ostream::operator<<(char const*)'
> checker.o(.text+0x7f2): undefined reference to `endl(ostream&)'
> gmake[3]: *** [kappfinder] Error 1
> gmake[3]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1'
> gmake: *** [all] Error 2
> *** Error code 2
>
> Any clues? The /usr/lib/libstdc++.a has, for example:
>
> W std::basic_ostream >& std::endlstd::char_traits >(std::basic_ostream >&)
> B std::cout
> B std::buf_cout
> U std::cout
> U std::buf_cout
I have the same problem exactly. All I could work out is that it's due
to checker.cpp including the old-fashioned iostream.h instead of
iostream. You can patch it to make it build easily enough...
--- checker.cpp.origWed Jun 19 15:49:04 2002
+++ checker.cpp Wed Jun 19 15:49:19 2002
@@ -20,7 +20,9 @@
#include
#include
-#include
+#include
+
+using namespace std;
#include
... but I doubt that's a good idea.
I haven't been able to find a library anywhere on my system that exports
the symbols I get when including iostream.h. Perhaps my -current build
is incomplete for some reason.
Here's an ultra-simple test case if it helps anyone:
fornost ~/tmp % cat test.cpp
#ifdef OLDE_STYLE
#include
#else
#include
using namespace std;
#endif
int main()
{
cout << "Hello, world." << endl;
return 0;
}
fornost ~/tmp % c++ -o test -Wall test.cpp
fornost ~/tmp % ./test
Hello, world.
fornost ~/tmp % c++ -o test -Wall -DOLDE_STYLE test.cpp
/var/tmp//ccjRtwx3.o: In function `main':
/var/tmp//ccjRtwx3.o(.text+0x14): undefined reference to `endl(ostream&)'
/var/tmp//ccjRtwx3.o(.text+0x21): undefined reference to `cout'
/var/tmp//ccjRtwx3.o(.text+0x26): undefined reference to
`ostream::operator<<(char const*)'
/var/tmp//ccjRtwx3.o(.text+0x2f): undefined reference to
`ostream::operator<<(ostream& (*)(ostream&))'
fornost ~/tmp % uname -a
FreeBSD fornost.ca.com 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Wed Jun 12
18:39:45 EST 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/FORNOST i386
--
Lachlan O'Dea <[EMAIL PROTECTED]> Computer Associates Pty Ltd
Webmaster Vet - Anti-Virus Software
http://www.vet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ troubles continue
Do you have cleaned your /usr/include/g++ directory from old gcc files? Jan On Wed, 2002-06-19 at 04:12, 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 >`/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder/apps' > gmake[3]: Entering directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder' > /bin/sh ../libtool --mode=link --tag=CXX c++ -DNDEBUG -DNO_DEBUG -O2 -O -march=i686 >-pipe -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT >-DQT_NO_ASCII_CAST-o kappfinder -L/opt/lib -pthread -L/opt/lib -R /opt/lib -R >/opt/lib -R /opt/lib -R /opt/lib main.o scanner.o checker.o kappfinder_meta_unload.o >-lkdeui > c++ -DNDEBUG -DNO_DEBUG -O2 -O -march=i686 -pipe -fno-exceptions -fno-check-new >-DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o kappfinder -pthread main.o >scanner.o checker.o kappfinder_meta_unload.o -L/opt/lib /opt/lib/libkdeui.so >/opt/lib/libkdecore.so -L/usr/lib /opt/lib/libDCOP.so /opt/lib/libkdefx.so -lqt-mt >-lpng -lz -lXext -lX11 -lSM -lICE -lXrender -lstdc++ -lm -lgcc -Wl,--rpath >-Wl,/opt/lib -Wl,--rpath -Wl,/opt/lib > checker.o: In function `checkDesktopFile(QString const&, QString)': > checker.o(.text+0x536): undefined reference to `cout' > checker.o(.text+0x543): undefined reference to `ostream::operator<<(char const*)' > checker.o(.text+0x575): undefined reference to `ostream::operator<<(char const*)' > checker.o(.text+0x585): undefined reference to `ostream::operator<<(char const*)' > checker.o(.text+0x6f1): undefined reference to `cout' > checker.o(.text+0x6fe): undefined reference to `ostream::operator<<(char const*)' > checker.o(.text+0x706): undefined reference to `endl(ostream&)' > checker.o(.text+0x7e1): undefined reference to `cout' > checker.o(.text+0x7ea): undefined reference to `ostream::operator<<(char const*)' > checker.o(.text+0x7f2): undefined reference to `endl(ostream&)' > gmake[3]: *** [kappfinder] Error 1 > gmake[3]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/ccd/ports/x11/kdebase3/work/kdebase-3.0.1' > gmake: *** [all] Error 2 > *** Error code 2 > > Any clues? The /usr/lib/libstdc++.a has, for example: > > W std::basic_ostream >& std::endlstd::char_traits >(std::basic_ostream >&) > B std::cout > B std::buf_cout > U std::cout > U std::buf_cout > > -mi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
