On Mon, 20 Mar 2000, Mark Ovens wrote:
# ldconfig -R /usr/obj/usr/src/lib/libc
or something like setenv LD_LIBRARY_PATH /usr/obj/usr/src/lib/libc
# config YOUR-KERNEL-HERE
Kris
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe [EMAIL
At 11:25 AM -0800 2000/3/21, Jordan K. Hubbard wrote:
Which areas are these? Again, please be specific so that I can
actually respond to this rather than going "What the hell is this man
even talking about?" :-)
Alright, as I get first-hand details of problems that I am
On Tue, Mar 21, 2000 at 12:46:38PM -0800, Kris Kennaway wrote:
On Mon, 20 Mar 2000, Mark Ovens wrote:
# ldconfig -R /usr/obj/usr/src/lib/libc
or something like setenv LD_LIBRARY_PATH /usr/obj/usr/src/lib/libc
Why would you set LD_LIBRARY_PATH? ``ldconfig -R '' worked fine
for
I am attempting to upgrade from 3.4-STABLE (cvsupped/built late last
week) to 4.0-STABLE cvsupped this morning into a clean /usr/src. The
supfile was /usr/src/share/examples/cvsup/stable-supfile with cvs-crypto
uncommented and RELENG_3 changed to RELENG_4. Whenever MAKE_KERBEROS4 is
uncommented
Hi
I am currently trying to get Bru2000 15.1 which is the elf version. I
keep getting an error upon ./install
that tells me
try bru -h ...elf binary type not known use brandelf
try bru.static -h ...elf binary type not know
I have tried the brandelf to the file bru still the same error.
At 11:20 AM 3/19/00 -0700, Warner Losh wrote:
In message [EMAIL PROTECTED] Brandon Fosdick writes:
: I thought of that, but I didn't know what the devices w/o slice numbers
: did. Guess I should have just tried it.
Devices w/o slice numbers are the "compatibility" devices. These map
to the
I ran into the exact same situation when I upgraded from 3.4,
commenting out the KERBEROS line in make.conf does indeed cause the
build to complete and you can perform the upgrade as provided in
/usr/src/UPDATING.
Once upgraded, I believe you can rebuild the system yet again
under 4.0 and enable
At 04:28 PM 3/19/00 -0800, Sameer R. Manek wrote:
I got this message on a cvsup performed today, at about Sun Mar 19 15:07:18
PST 2000, anyone else get a similar message? and should i be concerned about
it?
Not quite the same here: Should not be a problem, since the entire file is
fetched.
cvsupped today, 4.0-STABLE, make buildworld.
The compilation fails after a while.
=== rpcsvc
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/klm_prot.x -o klm_prot.h
rpcgen -C -h -DWANT_NFS3
In message [EMAIL PROTECTED] "Jeffrey J. Mountin" writes:
: Are you saying that da0a is (almost) functionally equivalent to da0s3a if
: slice 3 is the first FBSD slice. Thought they were for "dangerously
: dedicated" partitions.
No. That's not correct. While they are used in dangerously
On Tue, 21 Mar 2000, Carl Johan Madestrand wrote:
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/spray.x -o spray.h
unsigned hnt usec;
Last time I checked there was no type unsigned hnt in the standard
library. ;-) It should read unsigned int. Not sure who's fault that is.
About time this thread got its own subject line.
On Tue, 21 Mar 2000, David Murphy wrote:
Then we're in agreement on what an X.0 release should be. I'm
genuinely glad we understand each other, and would suggest that a note
similar to the above in the release notes/announcement would greatly
At 3:40 PM -0800 2000/3/21, Jordan K. Hubbard wrote:
Actually, those our outdated statements and I'm going to ask the
Walnut Creek CDROM postmaster to remove them. They only send a
confusing message. Thanks for the reminder. :)
So, you're saying that it's perfectly safe for me
13 matches
Mail list logo
