Dynamic linker bug in 3.4-RELEASE (I think)
I have a small program I wrote that uses sigwait and takes about 1 second to complete. If I run it over-and-over many times repeatedly, occasionally the dynamic linker will fail to resolve the "sigwait" symbol. Here is how I run it in tcsh: while (1) hw4-1 > /dev/null echo Done end And here is some output from the shell: ... Done Done Done Done Done Done Done Done Done /usr/libexec/ld-elf.so.1: hw4-1: Undefined symbol "sigwait" Done Done Done Done Done Done Done Done ... Is this a bug? Already fixed? Or should I file a PR. Thanks, Randall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Missing man pages: ld.so, sigwait()
sigwait is available but there's no man page. Also I don't find one for ld.so, though it's mentioned in the ldd man page. Worth a PR? Randall # grep sigwait /usr/include/signal.h int sigwait __P((const sigset_t *, int *)); int sigwaitinfo __P((const sigset_t *, siginfo_t *)); # apropos sigwait sigwait: nothing appropriate # man sigwait No manual entry for sigwait # apropos ld.so ld.so: nothing appropriate # man ld.so No manual entry for ld.so To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dynamic linker bug in 3.4-RELEASE (I think)
On Fri, 17 Mar 2000, Randall Hopper wrote: > I have a small program I wrote that uses sigwait and takes about 1 second > to complete. > > If I run it over-and-over many times repeatedly, occasionally the dynamic > linker will fail to resolve the "sigwait" symbol. > > Here is how I run it in tcsh: > > while (1) >hw4-1 > /dev/null >echo Done >end > > And here is some output from the shell: > > ... > Done > Done > Done > Done > Done > Done > Done > Done > Done > /usr/libexec/ld-elf.so.1: hw4-1: Undefined symbol "sigwait" > Done > Done > Done > Done > Done > Done > Done > Done > ... > > Is this a bug? Already fixed? Or should I file a PR. > > Thanks, > > Randall I think it is more likely you are exceeding your limit on number of file descriptors, so the dynamic linker isn't able to open the libraries. Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Desperate help upgrading from 3.2-R > 3.4-S
On Fri, 17 Mar 2000, Lester A. Mesa wrote: > and while running the make buildworld is where I get the following error: > > ===> share/doc/usd/13.viref > sed -e\ 's:\(\.so[\ \ ][\ > ]*\)\(vi.ref\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/ > docs/USD.doc/vi.ref/\2:' -e\ 's:\(\.so[\ \ ][\ > ]*\)\(ex.cmd.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib > /nvi/docs/USD.doc/vi.ref/\2:' -e\ 's:\(\.so[\ \][\ > ]*\)\(ref.so\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/ > docs/USD.doc/vi.ref/\2:' -e\ 's:\(\.so[\ \ ][\ > ]*\)\(set.opt.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contri > b/nvi/docs/USD.doc/vi.ref/\2:' -e\ 's:\(\.so[\ \ ][\ > ]*\)\(vi.cmd.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib > /nvi/docs/USD.doc/vi.ref/\2:' -e 's:^\.so index.so$::' > /usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/ > vi.ref | groff -mtty-char -Tascii -t -s -me -o1- > /dev/null > troff: fatal error: can't find macro file safer > *** Error code 1 > > Stop. > > ANY body knows why? or what do I have to do to make this work? These seemed to start showing up after asmodai's recent groff changes - several other people have had the same problem. I haven't seen any followup commits or messages addressing the problem yet - asmodai? Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Desperate help upgrading from 3.2-R > 3.4-S
This may be your problem. You either need to specify all, or each one individually. I have had trouble using the all option > src-all > src-crypto > src-eBones > src-secure You shouldn't need to use this in 3.x-stable > USA_RESIDENT= YES It is not necessary to upgrade from 3.2 if you are just trying to install a package. You can install the upgrade package, ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-3-stable/Latest/32upgrade.tgz You should then be able to install ports. If you still want to upgrade to 3.4 try cleaning /etc/obj and /usr/src and use this cvsupfile *default host=cvsup5.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_3 *default delete use-rel-suffix src-base src-bin src-contrib src-crypto src-etc src-games src-gnu src-include src-kerberosIV src-lib src-libexec src-release src-sbin src-secure src-share src-sys src-tools src-usrbin src-usrsbin *default tag=. ports-all doc-all Hope this helps, Jim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP: 3.x -> 4.0-STABLE upgrade instructions
Warner Losh wrote: > > When I tried the installkernel it installed things as /YOUR_KERNEL_HERE > > I'll have to update things. Well, for people who like to build multiple kernels like me, the above works... :-) Alas, I have kernel="/DCS" in my /boot/loader.conf. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP: 3.x -> 4.0-STABLE upgrade instructions
Marcel Moolenaar wrote: > > You can make a kernel like this: > cd /usr/src > make buildkernel KERNEL=YOUR_KERNEL_HERE > > The new `buildkernel' and `installkernel' targets make use of the tools > build by buildworld and effectively works around the bootstrap problem. IIRC, /etc/defaults/make.conf refers to KERNEL=your multiple kernels here, but that doesn't work for the install target (the strip doesn't work, I think). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
3 to 4 Upgrade, missing crypto bugs, and random thoughts
So having pushed myself through two machine upgrades in the last couple of days I've reproduced the missing crypto bug when compiling a kernel. I think I've isolated it. If you try to build a custom kernel with IPSEC options the make will bomb. This will happen even after the current UPDATING instructions are complete. But... if you do a buildworld and installworld with existing source after getting 4.0 running, then you can implement IPSEC in the kernel. Other than that I ran in to two FYIs One.. you might remind admins upgrading to write down the fstab before rebooting in to single user mode. It's good to know when you want to mount them. (including the swap partition for swapon) Two... I ran in to a disk space problem (disk space alloted by one of those 3.x sysinstall's) when doing a make installworld after the make -installworld. Admittedly I had built a custom kernel as well as a generic kernel when testing 'make buildkernel'. So I had /kernel /kernel.old /kernel.GENERIC /kernel.prev and /CUSTOMKERNEL taking up all of the disk space, but hopefully a userfriendly upgrade document might mention this condition, just in case someone wades in to the deep end only to find themselves buried deep in the -- - Tom Legg [EMAIL PROTECTED] http://www.shore.net/~tjlegg/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 3 to 4 Upgrade, missing crypto bugs, and random thoughts
On Fri, 17 Mar 2000, Tom Legg wrote: > I've reproduced the missing crypto bug when compiling a kernel. > I think I've isolated it. If you try to build a custom kernel with > IPSEC options the make will bomb. This will happen even after the > current UPDATING instructions are complete. You do have the src-sys-crypto sources, right? /usr/src/sys/crypto/? > But... if you do a buildworld and installworld with existing source > after getting 4.0 running, then you can implement IPSEC in the kernel. Hmm..I think you'd have to provide a build log showing where it failed without this step - I don't know why it would be the case. > Admittedly I had built a custom kernel as well as a generic kernel > when testing 'make buildkernel'. So I had /kernel /kernel.old > /kernel.GENERIC /kernel.prev and /CUSTOMKERNEL taking up all of the > disk space, but hopefully a userfriendly upgrade document might > mention this condition, just in case someone wades in to the deep > end only to find themselves buried deep in the Surely it's fairly obvious if you get an out of disk space message what the problem and fix is? Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.0
On Thu, 16 Mar 2000, David Bushong wrote: > > Well, I couldn't replicate this when I tried (under several different > > conditions). The only bug I found with compiling without crypto support > > was in tcpdump. Perhaps you have a stale /usr/obj? > > > I got this exact behavior from having only src-all in my supfile, and not > cvs-crypto. I still can't replicate this. I did the following: 1) cvsupped to 4.0-stable (4.0-release would be no different here, as nothing has changed to affect it except the tcpdump fix). 2) Blew away all traces of the installed crypto libraries/headers from my system. 3) Blew away my entire crypto/ and secure/ source directories 4) Did a 'make world'. It completed with no problems, and I also completed several other variations also with no problems. The only conclusion I can draw is that you have something stale about your system, perhaps old files in crypto/ or secure/ which it is detecting and trying to build with (or even just empty directories, although that breaks earlier in the build and always will have). Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
SMP oddity
Morning, Some of you will probably remember my request for opinions about SMP performance in 3.4-stable, and I went with it - I'm quite happy at the result as well, it runs beautifully. One very strange thing I've noticed though, from dmesg: CPU: Pentium III (686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Note how there is no megahurtz before "686-class CPU" as there normally is, (from another box); CPU: Celeron (400.91-MHz 686-class CPU) Has anyone seen this before? I don't think it's hurting anything, it runs perfectly well, I just find it curious, and mysteries give me headaches until they are solved =) I've attached my complete dmesg and kernel config in case it's something odd I'm doing that's causing it. Thanks again, I don't know what I'd do without the wonder of mailing lists. Matt -- Matt Heckaman [[EMAIL PROTECTED]|[EMAIL PROTECTED]] [Please do not send me] !Powered by FreeBSD/x86! [http://www.freebsd.org] [any SPAM (UCE) e-mail] # ALPHA.LUCIDA.QC.CA machine "i386" cpu "I686_CPU" ident ALPHA maxusers512 options NMBCLUSTERS=32768 # SMP options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=4 # number of busses options NAPIC=1 # number of IO APICs options NINTR=24# number of INTs # Main Options options INET# InterNETworking options FFS # Berkeley Fast Filesystem options FFS_ROOT# FFS usable as root device options MFS # Memory Filesystem options MFS_ROOT# MFS usable as root device options NFS # Network Filesystem options PROCFS # Process filesystem options MSDOSFS # MSDOS Filesystem options "EXT2FS"# Linux Filesystem options "CMD640"# work around CMD640 chip deficiency options "CD9660"# ISO 9660 Filesystem options "CD9660_ROOT" # CD-ROM usable as root. "CD9660" req'ed options "COMPAT_43" # Compatible with BSD 4.3 options SCSI_DELAY=5000 # Be pessimistic about Joe SCSI device options UCONSOLE# Allow users to grab the console options FAILSAFE# Be conservative options USERCONFIG # boot -c editor options VISUAL_USERCONFIG # visual boot -c editor # MISC Options options ATAPI # Enable ATAPI support for IDE bus options ATAPI_STATIC# we need this. options KTRACE # kernel tracing options QUOTA # enable disk quotas # POSIX Options options "P1003_1B" options _KPOSIX_PRIORITY_SCHEDULING options "_KPOSIX_VERSION=199309L" # SYSV Options options SYSVSHM options SYSVSEM options SYSVMSG # Firewall Options options IPFIREWALL # firewall options IPFIREWALL_VERBOSE # info about dropped packets options IPFIREWALL_FORWARD # transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100# limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT# allow everything by default config kernel root on da0 controller isa0 controller eisa0 controller pci0 controller fdc0at isa? port "IO_FD1" bio irq 6 drq 2 diskfd0 at fdc0 drive 0 diskfd1 at fdc0 drive 1 controller wdc0at isa? port "IO_WD1" bio irq 14 diskwd0 at wdc0 drive 0 diskwd1 at wdc0 drive 1 device acd0 device wfd0 controller ncr0 controller ahb0 controller ahc0 controller isp0 controller ahb0 controller dpt0 controller adw0 controller scbus0 device da0 device sa0 device cd0 # serial port/screen/keyboard stuff controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device vga0at isa? port ? conflicts device sc0 at isa? tty device npx0at isa? port IO_NPX irq 13 device sio0at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1at isa? port "IO_COM2" tty irq 3 device sio2at isa? disable port "IO_COM3" tty irq 5 device sio3at isa? disable port "IO_COM4" tty irq 9 # parallel port stuff controller ppbus0 device ppc0at isa? port? net irq 7 device nlpt0 at ppbus?
