HEADS UP: ports layout restructuring happening this weekend
Hello world, As those of you who have been following the ports list may know, we are changing the ports skeletons' layout in an effort to reduce the number of small directories and significantly speed up operation on the ports tree. This should especially help operations such as "CVS update", and will also reduce the number of i-nodes required to keep the whole tree around. The conversion will be done this weekend. It will only take a day or two. There should be no functional changes that you can see after the conversion (minus the bugs I may introduce, of course). However, during the conversion, the tree will be in an inconsistent state and attempts to use the tree will fail in most weird ways, so it is recommended that you cvsup the tree on or before Friday and do not cvsup again until I post an "all clear" message. Thanks, -PW To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: ports Makefiles being updated soon (forwarded)
FYI. -PW === From: [EMAIL PROTECTED] (Satoshi Asami) Subject: HEADS UP: ports Makefiles being updated soon To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Date: Fri, 7 Apr 2000 01:15:16 -0700 (PDT) Message-Id: [EMAIL PROTECTED] Hello world, As we have been discussing on the ports list, we have decided to introduce a slight syntax change to the port Makefiles regarding DISTNAME and PKGNAME. This change will be done this weekend. I will freeze the ports tree Friday night (U.S. Pacific Time) and a small group of volunteers will convert the entire tree in one pass. I will then unfreeze the tree and we can go back to business. I don't expect anything to break but since we are talking about over 3,000 ports, I can't guarantee that everything will go smooth. If you haven't cvsupped ports for a while, you may want to do it now. After the conversion, "old style" ports will no longer be accepted. Please read the handbook's porting section at, for instance, http://www.FreeBSD.org/handbook/porting.html#PORTING-SAMPLEM for details. (The above page seems to be still showing the old version -- the documentation change was committed today, so please check back later.) Also, make sure that you have the latest ports/Mk/bsd.port.mk if you are using anything from ports-current. This means, if you are cvsupping individual ports collections, you need to have "ports-base" in your cvsupfile. Thanks, Satoshi (and the friendly ports team) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sigisempty?
Hi,
How do I test if sigset_t is empty in -current? The xview sources
have this macro:
#define sigisempty(s) (!(*(s)))
which is ok for the old sigset_t (unsigned int) but obviously won't
work for the new one since it's a struct.
typedef struct __sigset {
unsigned int__bits[_SIG_WORDS];
} sigset_t;
Am I supposed to use a loop to iterate through the __bits and test if
all of them are zero or something?
Thanks,
Satoshi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
crashes
Have people seen these? === node82 1/2 === bash-2.02# gdb -k *.22 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... IdlePTD 2945024 initial pcb at 25fb60 panicstr: ffs_blkfree: freeing free block panic messages: --- panic: ffs_blkfree: freeing free block syncing disks... 244 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up on 2 buffers Uptime: 8d23h21m29s dumping to dev #wd/0x20001, offset 917632 dump ata0: resetting devices .. done 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc012fbd0 in boot () (kgdb) bt #0 0xc012fbd0 in boot () #1 0xc012ff54 in poweroff_wait () #2 0xc01c75d5 in ffs_blkfree () #3 0xc01cb626 in handle_workitem_freeblocks () #4 0xc01c9bbf in softdep_process_worklist () #5 0xc0156ff3 in sched_sync () #6 0xc0204620 in fork_trampoline () Cannot access memory at address 0x2000. (kgdb) quit === === node82 2/2 === bash-2.02# gdb -k *.23 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... IdlePTD 2945024 initial pcb at 25fb60 panicstr: page fault panic messages: --- panic: handle_allocdirect_partdone: lost dep syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c9832 stack pointer = 0x10:0xc0242fbc frame pointer = 0x10:0xc0242fc0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Uptime: 9h27m2s dumping to dev #wd/0x20001, offset 917632 dump ata0: resetting devices .. done 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc012fbd0 in boot () (kgdb) bt #0 0xc012fbd0 in boot () #1 0xc012ff54 in poweroff_wait () #2 0xc021226d in trap_fatal () #3 0xc0211f45 in trap_pfault () #4 0xc0211b2b in trap () #5 0xc01c9832 in acquire_lock () #6 0xc01cc45e in softdep_disk_io_initiation () #7 0xc0167173 in spec_strategy () #8 0xc0166cad in spec_vnoperate () #9 0xc01d813d in ufs_vnoperatespec () #10 0xc01d7bbd in ufs_strategy () #11 0xc01d810d in ufs_vnoperate () #12 0xc014f958 in bwrite () #13 0xc0154a0e in vop_stdbwrite () #14 0xc0154869 in vop_defaultop () #15 0xc01d810d in ufs_vnoperate () #16 0xc0150772 in vfs_bio_awrite () #17 0xc01d1921 in ffs_fsync () #18 0xc01d03d0 in ffs_sync () #19 0xc01595e3 in sync () #20 0xc012f9a3 in boot () #21 0xc012ff54 in poweroff_wait () #22 0xc01ccba1 in handle_allocdirect_partdone () #23 0xc01cc952 in softdep_disk_write_complete () #24 0xc0151bca in biodone () #25 0xc01ed8d2 in ad_interrupt () #26 0xc01eadf6 in ataintr () (kgdb) quit === === node87 1/1 === bash-2.02# gdb -k *.6 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... IdlePTD 2945024 initial pcb at 25fb60 panicstr: softdep_lock: lock held by -2 panic messages: --- panic: handle_allocdirect_partdone: lost dep syncing disks... panic: softdep_lock: lock held by -2 Uptime: 9d1h24m57s dumping to dev #wd/0x20001, offset 917632 dump ata0: resetting devices .. done 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc012fbd0 in boot () (kgdb) bt #0 0xc012fbd0 in boot () #1 0xc012ff54 in poweroff_wait () #2 0xc01c9851 in acquire_lock () #3 0xc01cc516 in initiate_write_filepage () #4 0xc01cc3e3 in softdep_disk_io_initiation () #5 0xc0167173 in spec_strategy () #6 0xc0166cad in spec_vnoperate ()
whither readline.h?
Dear currenters, /usr/include/readline/readline.h (and whatever else that's supposed to be in that directory) has been missing from 4-current and 3-stable snaps for awhile. Does anyone know why? Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/var/db/pkg/.mkversion
Hi, Some of you may have stumbled upon bsd.port.mk complaining about the lack of said file even after a make world. This was caused by my mistake of forgetting to update src/share/mk at the same time I committed the check to bsd.port.mk. I have since corrected it so if you cvsup again and make world again (actually just make install in src/share/mk), all will be well. As a workaround, echo 19990328 /var/db/pkg/.mkversion will work equally fine. Sorry for the trouble, -W To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
packages-4-current now being populated
I just started the first build of packages-4-current. I'm planning to recompile it and packages-3-stable once a week or so. Errors are at http://bento.freebsd.org/~asami/errorlogs/;, as usual. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
* From: Robert Watson rob...@cyrus.watson.org * away logged in via the network performing this recovery. Having the * drives automatically renumber themselves on the complete failure of one * drive (and it was fairly complete) would have been a disaster. This is Or just think ccd. There are people building disk servers out of IDE drives these days, and having the ccd configured in a wrong order could be disastrous. I have been running a SCSI server systems for a couple of years now and would have lost several 100GB volumes by now if the devices weren't wired down. (Sometimes the drives just won't show up at boot -- a power cycle usually cures that.) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ports
(Send messages like this to -ports next time, please) * I've noticed that as I'm constantly syncing my /usr/ports directory and * upgrading programs, the old packages stay there. If I pkg_delete them and * there's an unchanged file that exists in both the update and the original then * tat gets deleted too. Any way of cleanly removing old packages? Incidentally pkg_delete the old one before adding the new one? ;) * are the ports trees for all the FreeBSD releases the same one? I mean if I'm * running 2.2.x do I still get all the latest ports? ports-current (the tree you get if you cvsup ports now) only supports 3.1-stable and 4.0-current. If you're running 2.2.x, you are on your own. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs directories in BSD.local.dist
* Just curious as to why share/emacs and share/emacs/site-lisp are created by * BSD.local.dist instead of by the emacs ports which might want to use them? * It's not a big deal, but it seems to me that these aren't useful for the * general case of someone not wanting to install an emacs port (strange as that * may sound [1]). I suspect it's for historical reasons, but it doesnt mean it * can't be removed if sufficient time is deemed to have passed. Actually it's the other way around. It's created by BSD.local.dist so that people who don't need emacs don't have to install them. :) The problem is that many ports, some of which only install .el files as a by the way, you can use this from emacs too, fall over if this directory is not around. One solution is to add RUN_DEPENDS to emacs, which causes a whole lot of unhappiness, of course. So it's either those ports create the directory themselves or let BSD.local.dist do it. The latter was infinitely easier. :) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: The future of a.out support?
*Yes, a.out execution support will be standard in FreeBSD for at least * several more years. At some point it may become an option, but that's a * long way off. *The only thing people are talking about is support for building the * system binaries in a.out. We're moving to ELF because at some point our * make world source build system, not to mention the compiler toolchain, * will no longer support building a.out binaries. That sounds fine. However, there are still people stuck with a.out libraries out there (netscape comes to mind). Is the 3.1R installer going to include a.out libraries as an option? Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Netscape | Mozilla
* From: Luke l...@aus.org * linux_lib port. [why does it install into / anyways] You can put it anywhere and symlink to it, like sysinstall does now, but it has to be called /compat (or some other well-known place) because of the implementation. The string /compat/linux has to be hardcoded in the linux emulator binary. (If we move it to /usr/local/compat, people who use LOCALBASE other than /usr/local will be screwed, etc.) I know, I tried to change it before until I realized that it's not that easy. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup() macro in sys/malloc.h
* From: John Polstra j...@polstra.com * On 28-Jan-99 Bruce Evans wrote: Hey John, are you sure your mailer is Y2K compliant? Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* From: Steve Kargl s...@troutmask.apl.washington.edu * g77 is a frontend to the FSF compiler backend, and thus it is bound * to specific versions. So, it could become a support nightmare to ensure * a g77 port is in sync with the egcs backend in the base distribution. I don't think it would be that much of a support nightmare. Compilers in the base system don't change that often. If the port maintainer takes care to synchronize it with the system compiler, we should be fine. * It might even be impractical to try to build a standalone g77 port. That I don't know. I believe the compiler driver (gcc) can be instructed to call frontends in places other than /usr/libexec though. Maybe it would be feasible if we leave in hooks for that. (That is, if people want to compile fortran programs with /usr/bin/gcc.) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* The biggest problem has been that the port of g77 has not worked * properly for quite some time and in fact is currently marked as * broken. I would anticipate that this situation would not change much in That (and bug fix issues, as DavidO contends) all depends on the commitment of the maintainer (which there is none for the g77 port). Unless someone who uses g77 regularly steps up to maintain it, it will remain broken. This is the same for all ports, and I don't see why a fortran compiler should be an exception. Granted, if won't be blatantly broken if it's in the base distribution, but that's only because people will yell and scream if their make world doesn't work. If the amount of noise that generates is significantly different from what happens if it's a broken port, that's actually a pretty good argument *against* putting it in the base distribution, as it means we can keep g77 running only by annoying people who don't use it when it's broken. (1/2 :) This port has been marked broken since July last year. Sorry, but I just don't have a whole lot of sympathy for something that can stay broken that long without anyone fixing it. ;) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* From: Garrett Wollman woll...@khavrinen.lcs.mit.edu * A lot of people use a lot of things out of ports. Why should Fortran * be different? * * Because Berkeley Unix has /always/ included a FORTRAN compiler. Maybe that's because Berkeley Unix never had (until recently, anyway) a ports system? :) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* From: Glenn Johnson gjohn...@nola.srrc.usda.gov * Your points are well taken. I had a local port of g77 that built * against our current gcc. I never submitted it however for a couple * of reasons: * * 1. The port I had was for 0.5.19. This will build against our current *gcc, but g77 has advanced significantly since then. Unfortunately, the *newer versions need gcc 2.8. It was simply easier for me to use the *newer versions of g77 with gcc 2.8 or egcs release versions. Note that I *said easier for me; some colleagues of mine could/would not want to have *to maintain a compiler on their own. Yes, I was told this on a couple *of occasions. I can not see a point in me becoming the g77 0.5.19 port *maintainer when I am using newer versions of g77. I wasn't blaming you (or anyone in particular, for that matter). You don't even have to become a maintainer. But if you have a fix to the build problems, and you think it is an important enough piece of software for you and other people, please send in a patch so it can be built. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* The g77-0.5.19(.1) is *extremely* out-of-date. It should be dropped from * the ports collection, and if someone wants to use g77, then they should * install egcs. * * The newer versions of g77 do not work with gcc-2.7.2.x. The author of * g77 states that you shouldn't even try to back port g77 to any version * of gcc earlier than gcc-2.8 Well, Glenn said he got it to work with our compiler. :) But anyway, I don't have any problem to delete the g77 port for now. Is that ok with everyone else? Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* Maybe I misunderstood, but I thought Glenn got g77-0.5.19 to * work with our gcc-2.7.x. g77 is now at version 0.5.24. Those * micro numbers are significant changes, and these represent over * a years work on g77. No, I misunderstood. So Glenn got 0.5.19 to work, but it's very old. Anything newer than that (like the current 0.5.24) doesn't work with gcc 2.7.x and the author says don't bother trying. I got it now. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* From: David O'Brien obr...@nuxi.com * Alternately, I guess we could just have the code live in * /usr/ports/lang/f2c/src/, but I don't know if Satoshi wants /usr/ports * to expand like that. Eek. I don't think people will appreciate the ports collection suddenly exploding in size with things like that. (Portlint and tcpblast are exceptions since they are so small.) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* From: Steve Kargl s...@troutmask.apl.washington.edu * Yes, I recognize that this is problem. A partial solution might * be anoncvs to a shadow tree of the master ports repository. Only * those ports in the shadow tree which satisfy portlint and make; * make install; make package would get committed to the master * repository. * * Now, if Satoshi has read the above, could someone please revive him * and make sure he takes his heart medication ;-) Um, I'm still alive but can someone explain me why this can't be a regular port? Being useful to some but not the majority, no other parts of the system depending on it, this looks like a model citizen in the ideal ports world. :) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
* Well, actually I did f2c as a port, and it does indeed fit * inside the ports paradigm. Please, see my original email in * the thread. Yes, I know that. I was just wondering why people would want it otherwise. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Directory structure on current.freebsd.org
Sorry I'm jumping into this in the middle. * Oliver Fromme o...@dorifer.heim3.tu-clausthal.de wrote: * In releases/snapshots they're called axp and x86, while in * ports they're called alpha and i386. I'm not sure where this axp/x86 thing is coming from, but we are using alpha and i386 in ports (and /usr/src/sys) because that's what uname -m returns. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
mounting double-ended SCSI disks
Hi, In our project, we're trying to connect two PCs to both ends of a SCSI chain. I've got it somewhat working, but have a couple of questions re. mounting the filesystems. If I mount the filesystem from one machine (A) as read-write, then the other one (B) can't mount it read-write because the clean flag is not set. This is ok. Also, I can mount the disk read-only from both A and B. (I even read the entire contents of a 20GB partition from both machines at the same time -- worked without a hitch.) However, if I try to mount it from B read-only while A is mounting it read-write, it succeeds. This looks dangerous, as A writing data onto the disk could cause B's cache to go stale without B knowing it. Is it a good idea to allow read-only mounts of a dirty filesystem anyway? (The filesystem could be corrupted, right?) Another problem is if A is mounting it read-only and then B tries to mount it read-write. This succeeds and is dangerous for the same reason as the last example. Since A can't write anything to the disk, I guess there is no way we can avoid this situation. (The only way I could think of avoiding a crash due to stale cache data was to have A check the clean flag before every read, but that seems excessively expensive.) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mounting double-ended SCSI disks
* However, if I try to mount it from B read-only while A is mounting it * read-write, it succeeds. This looks dangerous, as A writing data onto * the disk could cause B's cache to go stale without B knowing it. Is * it a good idea to allow read-only mounts of a dirty filesystem anyway? * (The filesystem could be corrupted, right?) * * UFS/FFS doesn't expect anybody else to muck about on the device * while they have it open, and violating that is a bad idea, I cannot I know that, but that's not the point here. If the filesystem is marked dirty, it could very well be corrupted. Why am I allowed to mount it (even read-only)? I use softupdates on these filesystems, and my understanding is that it is theoretically safe to mount a filesystem without fsck after a crash if it's using softupdates. But I don't see mount checking that (if it is, it should allow read-write mounts too -- mount -f is not quite the same thing is it will override the check even for non-softupdates case). * tell if it would lead to panics, but I can imagine a couple of ways * it would become quantum mechanical in such a setup. * A couple of filesystem have been designed over the years which allow * for multiple machine access, but they tend to have lousy performance * because of caching being so inefficient. One of the better * implementations cheated, they stored the stuff in an Oracle database * on a third machine, but used a filesystem interface... To clarify, we're not trying to build a distributed filesystem here. We're planning to use the disks from both machines read-only most of the time, and unmount it from one machine if the other needs to write to it. I was just wondering what kind of safety belts the OS already has, so we can decide what else we need to implement. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
another texinfo buglet?
I cvsupped a couple of times, even blew away the entire contrib/texinfo and gnu/usr.bin/texinfo in the middle but I still get this === === makeinfo cc -O -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/local\ -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I../libintl -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c: In function `xrealloc': /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c:1205: parse error before `void' : === Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
* From: as...@freebsd.org (Satoshi Asami) * * * From: Chris Timmons skyn...@opus.cts.cwu.edu * * * make: don't know how to make Makefiles. Stop * * I've seen similar things, but they went away when I reduced the load * (other compilations in my case) on the server. How busy is your * server? Forgot to mention, this happens with a read-only NFS tree too. I was running builds on the client with a shared /usr/ports and WRKDIRPREFIX pointing to a local directory, and the build will topple over in the middle unable to find a Makefile on the server or something. That is the problem that went away with the server load. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: another texinfo buglet?
* ===
* === makeinfo
* cc -O -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/local\
-I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo
-I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo
-I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib
-I../libintl -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c
*
/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c:
In function `xrealloc':
*
/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c:1205:
parse error before `void'
* :
* ===
I looked into it a bit more. This file is definitely corrupted.
These are the lines around 1205:
===
/* Like realloc (), but barfs if there isn't enough memory. */
void *
xrealloc (pointer, nbytes)
void *pointer;
unsigned int nbytes;
{
void *temp;
if (!pointer)
temp = (void *)xmalloc (nbytes);
else
temp = (void *)realloc (pointer, nbytes);
/* If EXIT_VALUE is zero, print the full usage message to stdout.
Otherwise, just say to use --help for more info.
Then exit with EXIT_VALUE. */
void === 1205
usage (exit_value)
int exit_value;
{
if (exit_value != 0)
fprintf (stderr, _(Try `%s --help' for more information.\n), progname);
else
printf (_(Usage: %s [OPTION]... TEXINFO-FILE...\n\
===
Line 1205 is the void before usage(). It looks like (at least) the
second half of xrealloc() is missing.
Satoshi
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Which sound card now?
* From: br...@worldcontrol.com * So I am now mostly back the square 1. I'm still using an old GUS MAX, * which at the whim of FreeBSD-core may suddenly stop working. Just one point -- the axing of voxware was *not* approved by FreeBSD-core, and that's why it has been brought back. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
* From: Chris Timmons skyn...@opus.cts.cwu.edu * make: don't know how to make Makefiles. Stop I've seen similar things, but they went away when I reduced the load (other compilations in my case) on the server. How busy is your server? Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
