Re: Perl scripts that need rewiting - Any volunteers?
On Thu, 2002-05-09 at 07:41, Mark Murray wrote: On Thu, 2002-05-09 at 03:57, Mark Murray wrote: /usr/sbin/rmuser Wrapper round pw userdel? I took this one while the discussion was going on the past couple of days. It's at: http://home.pacbell.net/makonnen/rmuser.sh It also implements new functionality-- you can now specify a list of usernames on the command line or in a file (-f option) instead of deleting them one at a time. I guess I might as well take adduser too. Manpages too, please! :-) If you don't know *roff, no problem, write the words, and our friedly and excellent docs people will mark it up for you. The problem with writing man pages is, if you don't do it often enough you keep having to relearn it every time you do (which is why I wised up after about the third time or so this happened to me I created a cheat sheet). What would be cool is if the man pages were somehow integrated into the FreeBSD Documentation Project. That way I have to remember only the SGML tags. (yes, yes, I know: patches please? 8-) In any case, here's a proper patch (man page and all): http://home.pacbell.net/makonnen/rmuser.diff Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Resolution (Was: Re: The future of perl on FreeBSD)
On Thu, 09 May 2002 10:13:04 MST, Terry Lambert wrote: Uh, csh. Preferrably with tcsh extensions, so it won't run anywhere else. In a pinch, I guess you could use bash. cackles maniacally, and ducks Poul-Henning was too kind. You shouldn't be banned from the lists, you should be taken out back and shot until dead. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
On Fri, May 10, 2002 at 01:56:16AM -0600, Mike Makonnen wrote:
The problem with writing man pages is, if you don't do it often enough
you keep having to relearn it every time you do (which is why I wised up
/usr/share/examples/mdoc/example.{1,3,4}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
On Fri, 2002-05-10 at 02:56, David O'Brien wrote:
On Fri, May 10, 2002 at 01:56:16AM -0600, Mike Makonnen wrote:
The problem with writing man pages is, if you don't do it often enough
you keep having to relearn it every time you do (which is why I wised up
/usr/share/examples/mdoc/example.{1,3,4}
Thanks! I should have guessed.
Cheers,
Mike Makonnen.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
On Fri, May 10, 2002 at 01:56:16AM -0600, Mike Makonnen wrote: The problem with writing man pages is, if you don't do it often enough you keep having to relearn it every time you do (which is why I wised up after about the third time or so this happened to me I created a cheat sheet). What would be cool is if the man pages were somehow integrated into the FreeBSD Documentation Project. That way I have to remember only the SGML tags. We discussed the possibility of doing this at the last BSDCon BoF. Other UNIXes (i.e., Sun IIRC) are already doing this, using proprietary tools. Short answer: our tools just aren't there yet, but we're hoping. ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.nostarch.com/abs_bsd.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? Generally, this won't be necessary for properly organized code. The code in question is organized by software layering, right, so all you have to do is link the libraries in order? In other words, your answer is: This just a not-yet-implemented feature? = You might also want to consider using -Lpath -llibrary, = instead of trying to link .a's directly. What would this do? Make it all go through the library linking code, instead of the single object archive linking code. a .a file treated as an object is not the same as a library. What's the difference if all I have are the static libraries anyway? I actually tried this, and had the exactly same list of allegedly undefined symbols... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic after mount_ext2fs
This is a new problem beginning after a buildworld and build kernel yesterday, May 08 (still the old gcc 2.95.4): The system is quite stable until I mount an ext2 partition and attempt to list its directory. Immediately I get this error: syncing disks... panic: bdwrite: buffer is not busy. If I do a 'sync' first before listing the directory the error message changes to this: fatal trap 12: page fault while in kernel mode fault virtual address 0x18 fault code supervisor write, page not present Same thing happens even if the ext2fs is mounted read-only. Any other info I can supply that might be useful? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP - gcc-3.1 in progress!
On 2002-05-09 23:02, Peter Wemm wrote: John Baldwin wrote: So how many cases of beer does O'Brien get at Usenix now? :) Quite a few. :-) Let's not force him to join AAA before 5.0-RELEASE though. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Fri, May 10, 2002 at 01:54:50AM -0700, David E. O'Brien wrote:
obrien 2002/05/10 01:54:50 PDT
Modified files:
gnu/lib/csu Makefile
gnu/lib/libgcc Makefile
gnu/lib/libibertyMakefile
gnu/lib/libobjc Makefile
gnu/lib/libstdc++Makefile config.h
gnu/lib/libsupc++Makefile
gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc
Makefile.tgt
gnu/usr.bin/cc/c++ Makefile
gnu/usr.bin/cc/c++filt Makefile
gnu/usr.bin/cc/ccMakefile
gnu/usr.bin/cc/cc1 Makefile
gnu/usr.bin/cc/cc1obj Makefile
gnu/usr.bin/cc/cc1plus Makefile
gnu/usr.bin/cc/cc_drv Makefile
gnu/usr.bin/cc/cc_fbsd Makefile
gnu/usr.bin/cc/cc_int Makefile
gnu/usr.bin/cc/cc_tools Makefile auto-host.h freebsd-native.h
gnu/usr.bin/cc/cccp Makefile
gnu/usr.bin/cc/collect2 Makefile
gnu/usr.bin/cc/cpp Makefile
gnu/usr.bin/cc/cpp0 Makefile
gnu/usr.bin/cc/doc Makefile
gnu/usr.bin/cc/f77 Makefile
gnu/usr.bin/cc/f771 Makefile
gnu/usr.bin/cc/f77doc Makefile
gnu/usr.bin/cc/gcov Makefile
gnu/usr.bin/cc/protoize Makefile
gnu/usr.bin/cc/tradcpp0 Makefile
Log:
Bmake bits for Gcc 3.1.
Partially made possible by: [EMAIL PROTECTED]
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
(David, I'm copying -current so that others may benefit from this
patch while you're asleep.)
%%%
Index: cc1/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- cc1/Makefile10 May 2002 08:54:45 - 1.26
+++ cc1/Makefile10 May 2002 14:54:51 -
@@ -2,10 +2,10 @@
.include ../Makefile.inc
-.PATH: ../cc_tools ${GCCDIR}
+.PATH: ${GCCDIR}
PROG= cc1
-SRCS= main.c c-parse.c c-lang.c c-decl.c
+SRCS= main.c c-parse.y c-lang.c c-decl.c
BINDIR=/usr/libexec
NOMAN= 1
NOSHARED?=yes
@@ -17,17 +17,14 @@
#---
# C parser
-.ORDER: c-parse.c
-c-parse.c: c-parse.in
+c-parse.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
-CLEANFILES+= c-parse.c c-parse.y # insurance
+CLEANFILES= c-parse.y
.include bsd.prog.mk
Index: cc1obj/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1obj/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- cc1obj/Makefile 10 May 2002 08:54:46 - 1.20
+++ cc1obj/Makefile 10 May 2002 14:54:51 -
@@ -2,10 +2,10 @@
.include ../Makefile.inc
-.PATH: ../cc_tools ${GCCDIR}/objc ${GCCDIR}
+.PATH: ${GCCDIR}/objc ${GCCDIR}
PROG= cc1obj
-SRCS= objc-parse.c objc-act.c objc-lang.c main.c c-decl.c
+SRCS= objc-parse.y objc-act.c objc-lang.c main.c c-decl.c
BINDIR=/usr/libexec
NOMAN= 1
NOSHARED?=yes
@@ -17,18 +17,16 @@
#---
# objc parser
-.ORDER: objc-parse.c
-objc-parse.c: c-parse.in
+
+objc-parse.y: c-parse.in
sed -e /^ifc$$/,/^end ifc$$/d \
-e /^ifobjc$$/d \
-e /^end ifobjc$$/d \
- ${GCCDIR}/c-parse.in objc-parse.y
- ${YACC} -o objc-parse.c.in objc-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- objc-parse.c.in objc-parse.c
+ ${.ALLSRC} ${.TARGET}
-CLEANFILES+= objc-parse.c objc-parse.y # insurance
+CLEANFILES+= objc-parse.y
#---
Index: cc1plus/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1plus/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- cc1plus/Makefile10 May 2002 08:54:46 - 1.27
+++ cc1plus/Makefile10 May 2002 14:54:51 -
@@ -5,7 +5,7 @@
.PATH: ${GCCDIR}/cp ${GCCDIR}
PROG= cc1plus
-SRCS= parse.y cfns.h
+SRCS= parse.y y.tab.h parse.h cfns.h
SRCS+= main.c cp-lang.c
SRCS+= call.c class.c cvt.c decl.c decl2.c error.c except.c expr.c \
friend.c init.c lex.c mangle.c method.c pt.c ptree.c repo.c rtti.c \
@@ -20,21 +20,19 @@
DPADD+=${LIBCC_INT}
LDADD+=${LIBCC_INT}
-CLEANFILES+= parse.c parse.h y.tab.c y.tab.h cfns.h
+CLEANFILES= parse.y parse.h
Re: does the order of .a files matter?
Mikhail Teterin wrote: Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? Generally, this won't be necessary for properly organized code. The code in question is organized by software layering, right, so all you have to do is link the libraries in order? In other words, your answer is: This just a not-yet-implemented feature? Actually, it's it would not be necessary, if your code were organized to best common practices principles. Or more roughly It's not a feature. = You might also want to consider using -Lpath -llibrary, = instead of trying to link .a's directly. What would this do? Make it all go through the library linking code, instead of the single object archive linking code. a .a file treated as an object is not the same as a library. What's the difference if all I have are the static libraries anyway? I actually tried this, and had the exactly same list of allegedly undefined symbols... You can add -lxxx again, and it will only pull in those things that are missing. ... For my information: Why didn't you take John De Bowsky's advice to: ld $objlist `lorder $liblist | tsort -q` ??? I pointed you at tsort myself, but didn't provide the full command line like John did because I wanted the pain to be high enough that you would fix it the right way (reorganzing your library link order and using ranlib -- ppointed you at that, too) instead of glueing over the problem. Or are you on a holy crusade to get tsort incorporated into ld, so that most of the time, it will take a lot longer to link, with exatly the same results, since all the code everywhere else on the system has already solved the link order problem the right way? I have to say that, given a choice between make world taking several minutes longer and you not having to reorganize your code into logical component units, vs. it taking less time to do a make world, and one programmer having to *fix* their code, I have to pick you fixing your code. Also, this is a tools problem, and the tools provide a way (even if it's ugly) to get the behaviour you want, with a single option before your objects, and another one after. If you are going to convince anyone to make the change, it's going to have to be the tools people, and they are unlikely to be willing to take a hit on their benchmarks to please you, particularly if they've already externalized command line options so that you can solve your problem less automatically. By the tools people, I mean our linker vendor, the Free Software Foundation... not anyone in the FreeBSD Project. FreeBSD itself is *incredibly* unlikely to make a local hack to the GNU toolchain to support what you want being automatic, since David O'Brien, Peter Wemm, and others have sweat *blood* in order to get FreeBSD over to as much of the standard toolchain as humanly possible. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Who broke 'make clean' for ports ?
After a cvsup of 10 minutes ago either on 5.0-CURRENT and on 4.6-PRERELEASE (both of May 8, 02:46 CEST) making a # make clean into /usr/ports/deve/gettext spawn zillions(!) of make process, lead to cpu load average at 96.xx before a reboot :-( Up to yesterday it works. Doing this into others ports works... Riccardo. PS: I think this must sent to -stable and -ports too... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Who broke 'make clean' for ports ?
On 10-May-2002 (17:01:26/GMT) Riccardo Torrini wrote: into /usr/ports/deve/gettext s/deve/devel/ I use make clean to show dependencies before install/update. No, I don't use neither pkg_update nor portupgrade. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke 'make clean' for ports ?
In the last episode (May 10), Riccardo Torrini said: After a cvsup of 10 minutes ago either on 5.0-CURRENT and on 4.6-PRERELEASE (both of May 8, 02:46 CEST) making a # make clean into /usr/ports/deve/gettext spawn zillions(!) of make process, lead to cpu load average at 96.xx before a reboot :-( Up to yesterday it works. Doing this into others ports works... Syntax errors (or defining things that bsd.port.mk wants to control itself) in /etc/make.conf can cause this. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl scripts that need rewriting - Progress!
Hi,
On Thu, 09 May 2002 20:33:22 +0100
Mark Murray [EMAIL PROTECTED] said:
mark /usr/sbin/scriptdump
This script is from KAME. It seems that NetBSD doesn't install it.
Is someone actually using it? If okay, I'll change to don't install
it.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Who broke 'make clean' for ports ?
On Fri, May 10, 2002 at 12:26:56PM -0500, Dan Nelson wrote: In the last episode (May 10), Riccardo Torrini said: After a cvsup of 10 minutes ago either on 5.0-CURRENT and on 4.6-PRERELEASE (both of May 8, 02:46 CEST) making a # make clean into /usr/ports/deve/gettext spawn zillions(!) of make process, lead to cpu load average at 96.xx before a reboot :-( Up to yesterday it works. Doing this into others ports works... Syntax errors (or defining things that bsd.port.mk wants to control itself) in /etc/make.conf can cause this. there's a circular dependency that was just introduced to gettext. gettext now depends on expat, which depends on gmake, which depends on gettext. it's a known problem, and is being worked on. -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke 'make clean' for ports ?
On 10-May-2002 (17:26:56/GMT) Dan Nelson wrote:
After a cvsup of 10 minutes ago either on 5.0-CURRENT and on
4.6-PRERELEASE (both of May 8, 02:46 CEST) making a
# make clean
into /usr/ports/deve/gettext spawn zillions(!) of make process,
lead to cpu load average at 96.xx before a reboot :-(
Syntax errors (or defining things that bsd.port.mk wants to control
itself) in /etc/make.conf can cause this.
What things? I don't'think. Why into /usr/ports/astro/luna works?
Without changing my /etc/make.conf obviously... Anyway this are my
4.6 and 5.0 make.conf(s)
-8-[ 4.6-PRERELEASE ]-8
KERNCONF= SILOS
CFLAGS= -O2 -pipe
NOPROFILE= true
USA_RESIDENT= NO
SUP_UPDATE= yes
SUP=/usr/local/bin/cvsup
SUPFLAGS= -g -L 2 -z
SUPFILE=/usr/local/etc/cvsup.stable
PORTSSUPFILE= /usr/local/etc/cvsup.ports
SENDMAIL_MC=/etc/mail/silos.mc
# Resume
##FETCH_BEFORE_ARGS=-rR -o $${file}.resume
##FETCH_AFTER_ARGS= mv $${file}.resume $${file}
# Ports
WITHOUT_CUPS= yes
# qpopper
WITHOUT_IPV6= yes
-8-[ 5.0-CURRENT ]-8-
KERNCONF= TRUDY
CPUTYPE=p3
CFLAGS= -O2 -pipe
NOPROFILE= true
COMPAT3X= yes
COMPAT4X= yes
XFREE86_VERSION=4
USA_RESIDENT= NO
SUP_UPDATE= yes
SUP=/usr/local/bin/cvsup
SUPFLAGS= -g -L 2 -z
SUPFILE=/usr/local/etc/cvsup.current
PORTSSUPFILE= /usr/local/etc/cvsup.ports
SENDMAIL_MC=/etc/mail/trudy.mc
# Resume
##FETCH_BEFORE_ARGS=-rR -o $${file}.resume
##FETCH_AFTER_ARGS= mv $${file}.resume $${file}
# Ports
A4= yes # ghostscript-gnu
WITH_GPHOTO2= yes # sane-backends
WITH_GIMP= yes # sane-frontends
# mplayer
WITH_GUI= yes
WITH_DVD= yes
WITH_VORBIS=yes
# bocsh
WITH_BOCHS_CPU_LEVEL= 6
WITH_BOCHS_PROCESSORS= 1
# libmpeg2
WITH_SDL= yes
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Who broke 'make clean' for ports ?
On 10-May-2002 (17:31:32/GMT) Garrett Rooney wrote: there's a circular dependency that was just introduced to gettext. gettext now depends on expat, which depends on gmake, which depends on gettext. it's a known problem, and is being worked on. Ok, thanks. Sorry for alarm but I don't see any message before my own. Can I back-cvsup to a stable date? When (sh)it happens? Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke 'make clean' for ports ?
On Fri, May 10, 2002 at 07:41:44PM +0200, Riccardo Torrini wrote: On 10-May-2002 (17:31:32/GMT) Garrett Rooney wrote: there's a circular dependency that was just introduced to gettext. gettext now depends on expat, which depends on gmake, which depends on gettext. it's a known problem, and is being worked on. Ok, thanks. Sorry for alarm but I don't see any message before my own. Can I back-cvsup to a stable date? When (sh)it happens? the change is just a few hours old. you can just remove expat2 from the LIB_DEPENDS in textproc/gettext/Makefile and you should be fine for now. -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Friday 10 May 2002 12:51 pm, Terry Lambert wrote: = Mikhail Teterin wrote: =Is there a reason for it, or this just a not-yet-implemented =feature? It certainly seems like the latter -- why make the user =jump through all the sorting/reordering hoops? = = Generally, this won't be necessary for properly organized code. The = code in question is organized by software layering, right, so all you = have to do is link the libraries in order? = = In other words, your answer is: This just a not-yet-implemented feature? = Actually, it's it would not be necessary, if your code were = organized to best common practices principles. It is not my code. = Or more roughly It's not a feature. == You might also want to consider using -Lpath -llibrary, == instead of trying to link .a's directly. = =What would this do? = = Make it all go through the library linking code, instead of the = single object archive linking code. a .a file treated as an = object is not the same as a library. = = What's the difference if all I have are the static libraries anyway? = I actually tried this, and had the exactly same list of allegedly = undefined symbols... = You can add -lxxx again, and it will only pull in those things = that are missing. Thanks, this makes sense. = ... = = For my information: Why didn't you take John De Bowsky's advice to: = = ld $objlist `lorder $liblist | tsort -q` I tried that before I asked on the mailing list the first time. It did reduce the number of the undefined symbols, but not to zero. = ??? I pointed you at tsort myself, but didn't provide the full command = line like John did because I wanted the pain to be high enough that = you would fix it the right way (reorganzing your library link order = and using ranlib -- ppointed you at that, too) instead of glueing over = the problem. It would probably be quite beneficial if you dropped this paternalistic attitude. Pain high enough... Please... = Or are you on a holy crusade to get tsort incorporated into ld, so = that most of the time, it will take a lot longer to link, with exatly = the same results, since all the code everywhere else on the system has = already solved the link order problem the right way? [The term holy crusade does not help either -- it is not even paternalistic, just plain non-sense...] Tsort is ALREADY incorporated into ld in some shape, because object files on command line or within one .a CAN be misordered. All I ask, is why the collections of object files provided by different static libs are/can not be treated as one big collection. = I have to say that, given a choice between make world taking several = minutes longer and you not having to reorganize your code into logical = component units, vs. it taking less time to do a make world, and one = programmer having to *fix* their code, I have to pick you fixing your = code. Of course. Does not seem like it will come to this, however. = Also, this is a tools problem, and the tools provide a way (even if = it's ugly) to get the behaviour you want, with a single option before = your objects, and another one after. Hmm, no. The only reliable option is to either build a library of all libraries or link the the object files into the executable directly. This, BTW, shows how inconsistent the current situation is -- the linker does not mind misordered object files, but is very picky about the order of static libraries (shared ones are can be misordered too, AFAIK). I don't see how one can sincerely defend its lack of what still appears to be a missing feature. = By the tools people, I mean our linker vendor, the Free Software = Foundation... not anyone in the FreeBSD Project. Ok. Thanks for the pointer. = FreeBSD itself is *incredibly* unlikely to make a local hack to the = GNU toolchain to support what you want being automatic, since David = O'Brien, Peter Wemm, and others have sweat *blood* in order to get = FreeBSD over to as much of the standard toolchain as humanly possible. Many thanks to them. -mi -- ëÁË, ÷Ù ÒÁÚ×Å ÂÅÚ ÛÐÁÇÉ ÐÒÉÛÌÉ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke 'make clean' for ports ?
On 10-May-2002 (17:44:21/GMT) Garrett Rooney wrote: Ok, thanks. Sorry for alarm but I don't see any message before my own. Can I back-cvsup to a stable date? When (sh)it happens? the change is just a few hours old. you can just remove expat2 from the LIB_DEPENDS in textproc/gettext/Makefile and you should be fine for now. Yes, it works. Thanks again. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bin/cp breaks world
=== bin/cp cc -O -pipe -march=k6 -DVM_AND_BUFFER_CACHE_SYNCHRONIZED -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /home/src/bin/cp/cp.c cc1: warnings being treated as errors /home/src/bin/cp/cp.c: In function `copy': /home/src/bin/cp/cp.c:275: warning: deprecated use of label at end of compound statement -- Steve http://troutmask.apl.washington.edu/~kargl/ --- /home/src/bin/cp/cp.c.orig Fri May 10 10:56:22 2002 +++ /home/src/bin/cp/cp.c Fri May 10 10:57:10 2002 @@ -272,6 +272,7 @@ badcp = rval = 1; continue; default: + ; } /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FYI: breakage in libpam
cvsup'd @ 7:37am EDT 10 May ... 14256 cc -O -pipe -I/usr/src/lib/libpam/libpam -I/usr/src/lib/libpam/libpam/../../../contrib/openpam/include -DLIB_MAJ=2 -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/contrib/openpam/lib/pam_get_authtok.c -o pam_get_authtok.o 14257 cc1: warnings being treated as errors 14258 /usr/src/contrib/openpam/lib/pam_get_authtok.c: In function `pam_get_authtok': 14259 /usr/src/contrib/openpam/lib/pam_get_authtok.c:115: warning: implicit declaration of function `strcmp' 14260 *** Error code 1 14261 14262 Stop in /usr/src/lib/libpam/libpam. 14263 *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FYI: don't use -j with buildworld right now
Since the gcc upgrade, -j on buildworld seems to be temporarily out of order. Try building without it. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FYI: don't use -j with buildworld right now
And FYI, compiling with NO_WERROR=yes in make.conf is also a good idea right now, unless you're in the mood to fix warnings that appeared with the gcc upgrade due to changed gcc warnings. (Many of have been doing this for a while since the -Werror stuff with the kernel) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Fri, 10 May 2002, Robert Watson wrote: Since the gcc upgrade, -j on buildworld seems to be temporarily out of order. Try building without it. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services 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
Serial Console Speed
Hello all, I read here http://www.freebsd.org/smp/index.html in the known bugs section that Serial gdb does not work at 115200 baud. I found no open reports in the gnats database at the main site. Is this statement still true for current? Going to try gcc 3.1 :). regards, Galen Sampson __ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Mikhail Teterin wrote:
= For my information: Why didn't you take John De Bowsky's advice to:
=
= ld $objlist `lorder $liblist | tsort -q`
I tried that before I asked on the mailing list the first time. It
did reduce the number of the undefined symbols, but not to zero.
It's possible that the symbols are truly undefined (e.g. stat64),
but I think that is unlikely.
Here is what I think:
Your proximal problem is that your libraries are badly organized, and
therefore certain object files in them are not being pulled into the
linking process, because your order of operation on the objects is not
in dependency order, because of the improper organization.
It would probably be quite beneficial if you dropped this paternalistic
attitude. Pain high enough... Please...
If I sounded paternalistic in my answer, it's because the question
being asked is really a newby question about how linkers work, and
really doesn't belong on the -current list.
Here is a more comprehensive answer, which does not leave the solution
as an exercise for the student:
Most linkers don't do what you want, which is make up for programmer
incompetence by doing an automatic topological sort on all symbol
dependencies, regardless of where or in what type of file the symbol
is defined, because most linkers treat archives and libraries very
differently than lists of object files.
This is the technically correct thing for them to do.
The topological sorting interior to archives (libraries) is
supposed to be accomplished via ranlib:
ranlib generates an index to the contents of an archive,
and stores it in the archive. The index lists each symbol
defined by a member of an archive that is a relocatable
object file.
You may use `nm -s' or `nm --print-armap' to list this in-
dex.
An archive with such an index speeds up linking to the li-
brary, and allows routines in the library to call each
***
other without regard to their placement in the archive.
**
This only works intra-archive, not inter-archive. For inter-archive,
you are expected to order the archives in the proper order, and the
breakup of objects into archives is assumed to have been arranged by
the original programmer such that they are a directed acyclic graph.
That is, it is expected that if you have three libraries, then they
define an order set of symbol dependencies, such that *no two of the
following are simultaneously true*:
a-b-c, a-c-b, b-c-a, b-a-c, c-a-b, c-b-a
Any place the original programmer has violated this assumption means
linking the library more than once, e.g. if both are true:
a-b-c, b-c-a
Then you need:
$(OBJS) -la -lb -lc -la
Such code is, by definition, broken. Relinking the a library because
the c library consumes symbols defined in a but not consumed by
$(OBJS) is *an incredibly ugly workaround* to the fact that the
object in the libraries are not order in DAG order, and then linked in
exterior edge-of-DAG order.
In fact, the link order above indicates that the dependency order is
cyclic rather than acyclic (a depends on b depends on c depends on a ...
infinity).
Tsort is ALREADY incorporated into ld in some shape, because object
files on command line or within one .a CAN be misordered.
Within one .a, they are only permitted to be misordered if ranlib
has been run on the archive (see the quotation of the ranlib manual
page, above).
Within multiple .a's, they are handled differently, because linking
against a .a file does not necessarily pull in all of the object
files in the archive. *This is intentional; it is by design*.
All I ask, is why the collections of object files provided by different
static libs are/can not be treated as one big collection.
This is a conflicting requirement.
You can't have it both ways.
It's my understanding that you are making libraries in the first
place in order to get around command line length limitations, and
have settled upon archives, rather than incremental linking using
ld -r -o A.o ${A_OBJS}.
If this is the case, it would probably be a good idea to choose
which objects go into which library carefully, to avoid ending
up with undefined symbols.
Alternately, if you insist on using .a files directly, as if they
were normal object files, someone has already posted that you should
probably use the --whole-archive argument, so that the archive
contents aren't pulled in *only* if they define symbols which are
in the current undefined symbol list, but to pull them in unconditionally
(i.e. treat them as a list of object files instead of an archive).
= I have to say that, given a choice between make world taking several
= minutes longer and you not having to reorganize your code into logical
= component units, vs. it taking less time to do a make world, and
Re: Serial Console Speed
Serial console and remote GDB were working just fine for me ever since that entry has been added to the task SMPng unresolved issues list. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fix order of directories in rc.shutdown
The enclosed patch fixes the order of script execution so the directory
order is also reversed. The current behavior is to have directories
traversed in the same order as at startup, but have the scripts in the
directories reversed. I just changed it so it builds the script list
forward (like for startup), but then reverses the entire list before
execution.
-gordon
--- /etc/rc.shutdownThu Apr 11 14:39:20 2002
+++ rc.shutdown Fri May 10 14:25:35 2002
-52,6 +52,18
. /etc/rc.conf
fi
+# reverse_list list
+# print the list in reverse order
+#
+reverse_list()
+{
+ _revlist=
+ for _revfile in $*; do
+ _revlist=$_revfile${script_name_sep}$_revlist
+ done
+ echo $_revlist
+}
+
# Write some entropy so the rebooting /dev/random can reseed
#
case ${entropy_file} in
-109,13 +121,13
for dir in ${local_startup}; do
if [ -d ${dir} ]; then
for script in ${dir}/*.sh; do
- slist=${script}${script_name_sep}${slist}
+ slist=${slist}${script_name_sep}${script}
done
fi
done
script_save_sep=$IFS
IFS=${script_name_sep}
- for script in ${slist}; do
+ for script in `reverse_list ${slist}`; do
if [ -x ${script} ]; then
(set -T
trap 'exit 1' 2
Re: Serial Console Speed
On 10-May-2002 Alexander Kabaev wrote: Serial console and remote GDB were working just fine for me ever since that entry has been added to the task SMPng unresolved issues list. At 115200? -- 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: Serial Console Speed
At 115200? I have BOOT_COMCONSOLE_SPEED= 115200 in my make.conf and CONSPEED=115200 in kernel config files on two -CURRENT boxes. GDB and console are working fine between 1.2GHz Atlon and older PII IBM ThinkPad. On Fri, 10 May 2002 17:43:14 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: On 10-May-2002 Alexander Kabaev wrote: Serial console and remote GDB were working just fine for me ever since that entry has been added to the task SMPng unresolved issues list. At 115200? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make.conf and -CURRENT
Hello, Is the lack of /etc/defaults/make.conf intentional? an oversite? or perhaps something that I have messed up on my end? I have run cvsup/mergemaster (18:30PM EST May 10. 2002), and that changes nothing. /usr/src/etc/*/* does not contain said file, the only place it does exist is in /usr/share/examples/etc. Thanks Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Friday 10 May 2002 04:35 pm, Terry Lambert wrote:
= Mikhail Teterin wrote:
= = For my information: Why didn't you take John De Bowsky's advice to:
= =
= = ld $objlist `lorder $liblist | tsort -q`
=
= I tried that before I asked on the mailing list the first time. It
= did reduce the number of the undefined symbols, but not to zero.
=
= It's possible that the symbols are truly undefined (e.g. stat64),
= but I think that is unlikely.
= It would probably be quite beneficial if you dropped this paternalistic
= attitude. Pain high enough... Please...
=
= If I sounded paternalistic in my answer, it's because the question
= being asked is really a newby question about how linkers work, and
= really doesn't belong on the -current list.
It looked (and still looks) to me like a bug or an incompleteness. That's
why I involved -current into it. The -stable is unlikely to make the changes
neccessary, but with -current I had hope.
= Here is a more comprehensive answer, which does not leave the solution
= as an exercise for the student:
=
= Most linkers don't do what you want, which is make up for programmer
= incompetence by doing an automatic topological sort on all symbol
= dependencies, regardless of where or in what type of file the symbol
= is defined, because most linkers treat archives and libraries very
= differently than lists of object files.
=
= This is the technically correct thing for them to do.
Doing what you explain by incompetence is no different from listing the
object files (.o) on the linker's command line in an arbitrary order --
say, alphabetically, as done by most of the FreeBSD's own Makefiles. Not
out of incompetence, but rather for neatness sake. The fact, that the
linker has no problems in this case shows the existing inconsitency.
= This only works intra-archive, not inter-archive. For inter-archive,
= you are expected to order the archives in the proper order, and the
This expectation is not even documented anywhere...
= Tsort is ALREADY incorporated into ld in some shape, because object
= files on command line or within one .a CAN be misordered.
= Within one .a, they are only permitted to be misordered if ranlib
= has been run on the archive (see the quotation of the ranlib manual
= page, above).
Your attempt to dodge explaining the other case -- that of misordered
object files _on command line_ has been logged.
= Within multiple .a's, they are handled differently, because linking
= against a .a file does not necessarily pull in all of the object files
= in the archive. *This is intentional; it is by design*.
Design of what? Of linker? If so, the design is inconsistent (broken?),
for it handles the same entities (object files) differently depending on
how they are given to it (in a single .a, on command line, in multiple
.a files).
= It's my understanding that you are making libraries in the first place
= in order to get around command line length limitations, and have
= settled upon archives, rather than incremental linking using ld -r -o
= A.o ${A_OBJS}.
Not quite. The software's original build is broken up into dozens of
interdependent libraries. They had no problems linking together on
neither Solaris, nor AIX, nor HP-UX, nor NT.
= If this is the case, it would probably be a good idea to choose
= which objects go into which library carefully, to avoid ending
= up with undefined symbols.
I'm not (yet) developing this software. I'm just trying to port it!
= Alternately, if you insist on using .a files directly, as if they
= were normal object files, someone has already posted that you should
= probably use the --whole-archive argument, so that the archive
= contents aren't pulled in *only* if they define symbols which are in
= the current undefined symbol list, but to pull them in unconditionally
= (i.e. treat them as a list of object files instead of an archive).
That suggestion I missed. But it looks like --whole-archive will suck in
everything, including the really unneeded objects.
Perhaps, the linkers on the commercial OSes I listed do use some smarter
equivalent of ``--whole-archive'' by default. IMO, it makes sense, since
those, who know, THEIR libraries are organized properly, and care for
the speed of linking can always add --no-whole-archive (or equivalent)
to THEIR makefiles -- speeding up their ``build world''.
= In the end, you will have to have already been told to solve it, in
= this thread, and which I have laid out, in no uncertain terms, in this
= email.
I think, the terms I used to say, that I already solved my problem,
were no less uncertain. My immediate problem that is.
I'm now readying my horse and armor for the trip to figure out, why is
this sort of gymnastics only needed with the OSF toolchain (actually, I
may be wrong here, since I did not _personally_ verify this thing links
on the other systems without the hoop-jumping).
= This, BTW, shows how inconsistent the current situation is -- the
=
Re: make.conf and -CURRENT
On Fri, May 10, 2002 at 06:37:11PM -0400, Jeff Ito wrote: Hello, Is the lack of /etc/defaults/make.conf intentional? an oversite? or perhaps something that I have messed up on my end? I have run cvsup/mergemaster (18:30PM EST May 10. 2002), and that changes nothing. /usr/src/etc/*/* does not contain said file, the only place it does exist is in /usr/share/examples/etc. It's intentional. Since everything was commented out examples and not actual defaults, it was moved to /usr/share/examples/etc. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg38159/pgp0.pgp Description: PGP signature
RE: does the order of .a files matter?
Order-dependency on the link command line has been common behaviour
in linkers forever as far as I know. This includes the FSF GNU linker,
as well as the system linker shipped with Unix systems.
It is a useful feature, allowing one to insert other objects in
front, e.g. to override 'malloc' with a debugging version.
Some linkers have a -recurse or --recurse switch which causes them
to, once they'e reached the end of the pass, loop until there are
no undefineds or no symbols have been pulled in.
The approach I prefer over multiply listing archives is to
use -u to explicitly pull in the offending reverse dependency.
Quoting from the GNU ld 'info' page:
The linker will search an archive only once, at the location where
it is specified on the command line. If the archive defines a
symbol which was undefined in some object which appeared before
the archive on the command line, the linker will include the
appropriate file(s) from the archive. However, an undefined
symbol in an object appearing later on the command line will not
cause the linker to search the archive again.
See the `-(' option for a way to force the linker to search
archives multiple times.
You may list the same archive multiple times on the command line.
This type of archive searching is standard for Unix linkers.
However, if you are using `ld' on AIX, note that it is different
from the behaviour of the AIX linker.
And:
`-( ARCHIVES -)'
`--start-group ARCHIVES --end-group'
The ARCHIVES should be a list of archive files. They may be
either explicit file names, or `-l' options.
The specified archives are searched repeatedly until no new
undefined references are created. Normally, an archive is
searched only once in the order that it is specified on the
command line. If a symbol in that archive is needed to resolve an
undefined symbol referred to by an object in an archive that
appears later on the command line, the linker would not be able to
resolve that reference. By grouping the archives, they all be
searched repeatedly until all possible references are resolved.
Using this option has a significant performance cost. It is best
to use it only when there are unavoidable circular references
between two or more archives.
Now, I suggest stopping the flame war, or take it somewhere else,
this really doesn't have anything to do with FreeBSD.
--don
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
** HEADS UP ** if you have problems buliding the new GCC
[bogus From: address, because people cannot be bothered to respect Reply-To:] Due to the way CVS works, it sometimes does not notice when we do repository surgery. We now have one of those times for src/contrib/gcc. So, if you have trouble building the new GCC w/o -j (dies in src/gnu/usr.bin/cc/cc_tools); you need to: cd /usr/src/contrib rm -rf gcc cvs up -PdA gcc that is all, -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Some ports fail on -current because ${BINOWN} and ${BINGRP} seems to be not defined
Hi,
I am currently checking bento's port building errors on -current. I have
found some ports, e.g. audio/cam [1], that could not be installed
because ${BINOWN} and ${BINGRP} seems to be not defined. They end up
with the error:
install: -g: Invalid argument
coming from things like:
install -c -m 755 -o -g cam /usr/local/bin
Any ideas? Any hints?
Regards,
Olli
1. http://bento.freebsd.org/errorlogs/5-latest/cam-1.02.log
--
Institute for Software TechnologyInstitute for Information Systems
Department of Computing Science, Federal Armed Forces University Munich
--- http://ist.unibw-muenchen.de/People/obraun/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Mikhail Teterin wrote:
= Most linkers don't do what you want, which is make up for programmer
= incompetence by doing an automatic topological sort on all symbol
= dependencies, regardless of where or in what type of file the symbol
= is defined, because most linkers treat archives and libraries very
= differently than lists of object files.
=
= This is the technically correct thing for them to do.
Doing what you explain by incompetence is no different from listing the
object files (.o) on the linker's command line in an arbitrary order --
say, alphabetically, as done by most of the FreeBSD's own Makefiles. Not
out of incompetence, but rather for neatness sake. The fact, that the
linker has no problems in this case shows the existing inconsitency.
You are wrong.
If you had listed the .o files seperately on the command line,
then the link would have succeeded, had you not exceeded the
command line length limit.
An archive is not a macro expansion for a list of the object
files it contains.
= This only works intra-archive, not inter-archive. For inter-archive,
= you are expected to order the archives in the proper order, and the
This expectation is not even documented anywhere...
Yes, it is. You need to read the ld and ar and ranlib man
pages, paying heavy attention to just what a static archive is
and isn't.
= Tsort is ALREADY incorporated into ld in some shape, because object
= files on command line or within one .a CAN be misordered.
I saw this. It's irrelevent because you said or within one .a.
It's not true for the within one .a, either (that's what ranlib
is for).
The command line linking is not handled by a topological sort.
It's handled by the fact that when you list objects on the command
line, you are forcing their incorporation into the resulting linker
output. When you specify archives on the command line, you are NOT;
you are saying pull the objects in this thing in, if you see that
they resolve unresolved externals *known to you at the time you
encounter the archive, in order, on the command line*.
Very different.
= Within one .a, they are only permitted to be misordered if ranlib
= has been run on the archive (see the quotation of the ranlib manual
= page, above).
Your attempt to dodge explaining the other case -- that of misordered
object files _on command line_ has been logged.
I'm not attempting to dodge anything. Your expectations of an
archive being treated as a list of the objects archived in it,
is wrong.
= Within multiple .a's, they are handled differently, because linking
= against a .a file does not necessarily pull in all of the object files
= in the archive. *This is intentional; it is by design*.
Design of what? Of linker?
Of the interaction of archive files and the linker.
If so, the design is inconsistent (broken?),
In your opinion.
for it handles the same entities (object files) differently depending on
how they are given to it (in a single .a, on command line, in multiple
.a files).
Your opinion disagrees with the documentation. At the command
line, type info ld; if you read the documentation, you will find:
The linker will search an archive only once, at the location where
it is specified on the command line. If the archive defines a
symbol which was undefined in some object which appeared before
the archive on the command line, the linker will include the
appropriate file(s) from the archive. However, an undefined
symbol in an object appearing later on the command line will not
cause the linker to search the archive again.
See the `-(' option for a way to force the linker to search
archives multiple times.
You may list the same archive multiple times on the command line.
This type of archive searching is standard for Unix linkers.
However, if you are using `ld' on AIX, note that it is different
from the behaviour of the AIX linker.
= It's my understanding that you are making libraries in the first place
= in order to get around command line length limitations, and have
= settled upon archives, rather than incremental linking using ld -r -o
= A.o ${A_OBJS}.
Not quite. The software's original build is broken up into dozens of
interdependent libraries. They had no problems linking together on
neither Solaris, nor AIX, nor HP-UX, nor NT.
NT and AIX, I understand.
If you didn't have a problem on Solaris, I'd have to guess that
you used the C++ compiler, rather than the standard SunSoft ANSI
C compiler.
Solaris does a number of things that it shouldn't, and it leads
to programmers making bad assumptions about things like static
declaration of template class constructor instances.
On occasion, rather than generating link time errors, you end up
with run time errors, instead, which is really bad, if your testing
doesn't test each and every code path in your code.
= If this is the case, it would
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
These changes are wrong.
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
...
-c-parse.c: c-parse.in
+c-parse.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
The malloc usage is in the Byacc output, not the input.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Don Bowman wrote: Now, I suggest stopping the flame war, or take it somewhere else, this really doesn't have anything to do with FreeBSD. Yeah; it looks like he was really looking for an explanation of the failure of the OSF toolchain, and might not even be compiling on FreeBSD at all in the first place... 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make.conf and -CURRENT
On Fri, May 10, 2002 at 06:37:11PM -0400, Jeff Ito wrote: Hello, Is the lack of /etc/defaults/make.conf intentional? an oversite? or perhaps something that I have messed up on my end? I have run cvsup/mergemaster (18:30PM EST May 10. 2002), and that changes nothing. /usr/src/etc/*/* does not contain said file, the only place it does exist is in /usr/share/examples/etc. sysctl.conf is also missing. If its not there, it doesn't get parsed. You only need make.conf if you wish to put stuff in there. same with rc.conf, except everyone puts something in rc.conf -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make.conf and -CURRENT
On Fri, May 10, 2002 at 05:40:11PM -0500, David W. Chapman Jr. wrote: On Fri, May 10, 2002 at 06:37:11PM -0400, Jeff Ito wrote: Hello, Is the lack of /etc/defaults/make.conf intentional? an oversite? or perhaps something that I have messed up on my end? I have run cvsup/mergemaster (18:30PM EST May 10. 2002), and that changes nothing. /usr/src/etc/*/* does not contain said file, the only place it does exist is in /usr/share/examples/etc. sysctl.conf is also missing. If its not there, it doesn't get parsed. You only need make.conf if you wish to put stuff in there. same with rc.conf, except everyone puts something in rc.conf N/m on the sysctl.conf I think that one exists now. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org 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 /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- stage 4: building libraries -- === libkdb ... /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c: In function `kdb_encrypt_key': /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type === libkrb === libtelnet cc1: warnings being treated as errors /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c: In function `kerberos4_cksum': /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable code at beginning of switch statement *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib/libtelnet. *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib. *** 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. *** 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
pam su
Hello all, After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a mergemaster I am seeing the following on the console when I su: May 10 22:14:38 su: using dynamic pam_nologin.so May 10 22:14:38 su: adding pam_nologin.so to cache May 10 22:14:38 su: pam_lastlog.so: pam_sm_authenticate(): Undefined symbol pam_sm_authenticate May 10 22:14:38 su: pam_lastlog.so: pam_sm_setcred(): Undefined symbol pam_sm_setcred May 10 22:14:38 su: pam_lastlog.so: pam_sm_acct_mgmt(): Undefined symbol pam_sm_acct_mgmt May 10 22:14:38 su: pam_lastlog.so: pam_sm_chauthtok(): Undefined symbol pam_sm_chauthtok May 10 22:14:38 su: using dynamic pam_lastlog.so May 10 22:14:38 su: adding pam_lastlog.so to cache May 10 22:14:38 su: using dynamic pam_deny.so May 10 22:14:38 su: adding pam_deny.so to cache May 10 22:14:38 su: releasing pam_nologin.so May 10 22:14:38 su: releasing pam_deny.so May 10 22:14:38 su: pam_start(su) succeeded May 10 22:14:38 su: calling pam_sm_authenticate() in pam_rootok.so May 10 22:14:38 su: User is not superuser May 10 22:14:38 su: pam_rootok.so: pam_sm_authenticate(): authentication error May 10 22:14:38 su: calling pam_sm_authenticate() in pam_self.so May 10 22:14:38 su: pam_self.so: pam_sm_authenticate(): authentication error May 10 22:14:38 su: calling pam_sm_authenticate() in pam_wheel.so May 10 22:14:38 su: Options processed May 10 22:14:38 su: Got target user: root uid: 0 May 10 22:14:38 su: Got user: galen May 10 22:14:38 su: User's primary uid, gid: 1000, 1000 May 10 22:14:38 su: Not superuser May 10 22:14:38 su: Checking group May 10 22:14:38 su: Got group: wheel May 10 22:14:38 su: pam_wheel.so: pam_sm_authenticate(): ignore this module May 10 22:14:38 su: calling pam_sm_authenticate() in pam_opie.so May 10 22:14:38 su: Options processed May 10 22:14:38 su: Got user: root May 10 22:14:38 su: pam_opie.so: pam_sm_authenticate(): authentication error May 10 22:14:38 su: calling pam_sm_authenticate() in pam_opieaccess.so May 10 22:14:38 su: pam_opieaccess.so: pam_sm_authenticate(): success May 10 22:14:38 su: calling pam_sm_authenticate() in pam_unix.so May 10 22:14:38 su: Options processed May 10 22:14:38 su: Got user: root May 10 22:14:38 su: Doing real authentication May 10 22:14:41 ip68-6-109-149 su: galen to root on /dev/ttyp0 Is this normal? regards, Galen Sampson __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
