to wipe out the front-end of the boot disk. I then re-installed
the 4.0 system a 3rd time and it now boots normally. I am unable to
explain why this happened, but hope that someone with more experience
with the sysinstall/boot code can shed some light on it.
No, that's just pretty weird.
I've been compiling things w/in /usr/src/ , but haven't done a ``make
world'' with EGCS in-place in /usr/src due to the `cpp w/c++'' problem.
Where exactly does it die? We should at least make it easily possible
to get the build environment configured the way it's supposed to
look so that
I've been compiling things w/in /usr/src/ , but haven't done a ``make
world'' with EGCS in-place in /usr/src due to the `cpp w/c++'' problem.
Where exactly does it die?
Lets assume one is not trying to hook EGCS into /usr/src yet.
cd /foo/src/gnu/usr.bin/cc
make obj
make depend
make -k
/foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params
I'd be very curious to see how gen-params is calling c++ and/or cpp in
this case.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Fri, Mar 12, 1999 at 02:29:27AM -0800, Jordan K. Hubbard wrote:
/foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params
I'd be very curious to see how gen-params is calling c++ and/or cpp in
this case.
+ c++ -v -O -c dummy.C
Using builtin specs.
gcc version egcs-2.91.63
On Fri, 12 Mar 1999, David O'Brien wrote:
On Fri, Mar 12, 1999 at 02:29:27AM -0800, Jordan K. Hubbard wrote:
/foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params
I'd be very curious to see how gen-params is calling c++ and/or cpp in
this case.
+ c++ -v -O -c dummy.C
Can somebody comment on
http://www.cs.columbia.edu/~ezk/research/cryptfs/node3.html#SECTION00036000
and on bringing the other goodies from
http://www.cs.columbia.edu/~ezk/research/index.html
into -current and, perhaps, -stable? Right now, we only have am-utils...
-mi
I had the same problem.. I had to reinstal the old booteazy off a backup
before my system would boot again.
I have booteasy on dsk0, and used fdisk -b on dsk1 after installing hte
new bootblocks (3stage). It stopped booting and nothing I could do woul
dmake it boot till I manufactured a new
Hi,
under -current I get during kernel compile:
...
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-ansi -nostdinc -I- -I. -I../.. -I../../../include -DCOMPAT_LINUX_THREADS
-DKERNEL
Heads up! 4.x developers / testers. A bunch of bug fixes have been
committed, including a big involved one that solves problems related in
the getnewbuf() thread by basically rewriting getnewbuf().
At least a half dozen bug fixes by various authors have been committed in
w/o device pcic into kernel config (using kldload pcic) still:
loading kernel
pccard.o: In function `unregister_device_interrupt':
pccard.o(.text+0x362): undefined reference to `unregister_pcic_intr'
pccard.o: In function `pccard_alloc_intr':
pccard.o(.text+0x718): undefined reference to
In message 19990312195615.26156.rocketm...@send101.yahoomail.com Valentin
Shopov writes:
: w/o device pcic into kernel config (using kldload pcic) still:
:
: loading kernel
: pccard.o: In function `unregister_device_interrupt':
: pccard.o(.text+0x362): undefined reference to
Hmm environment variables?
That is my guess.. but I don't know an easy way to printout the entire
environtment a program sees.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the
On Fri, 12 Mar 1999, David O'Brien wrote:
Hmm environment variables?
That is my guess.. but I don't know an easy way to printout the entire
environtment a program sees.
How about hacking cpp so that it does 'system(env /tmp/somefile)' as
the first thing.
--
Doug Rabson
Doug Rabson wrote:
On Fri, 12 Mar 1999, David O'Brien wrote:
Hmm environment variables?
That is my guess.. but I don't know an easy way to printout the entire
environtment a program sees.
How about hacking cpp so that it does 'system(env /tmp/somefile)' as
the first thing.
I
Folks,
Currently, the English versions of the FAQ and Handbook install in to
/usr/doc/FAQ and /usr/doc/handbook respectively.
The language specific versions install into /usr/doc/{language code}/FAQ
and /usr/doc/{language code}/handbook respectively.
If no one has any objections, I'd like to
Folks,
If you're used to running make release I'd appreciate you trying the
following and letting me know what happens. This is so that I can check
that the DocBook version of the Handbook is being installed correctly.
After checking out the most recent version of doc-all, please do the
1. Install the textproc/docproj port. This is a meta port which pulls
in a few others. You do *not* need the TeX installation with this
(not including it is the default, so you don't need to do anything
out of the ordinary).
This is done by make release in the chroot area.
The only configuration which currently works correctly is to remove the
kldload of the pcic module from /etc/rc.pccard and compile everything
else statically into the kernel.
Every other variation is *broken*.
w/o device pcic into kernel config (using kldload pcic) still:
loading kernel
Julian Elischer wrote:
I had the same problem.. I had to reinstal the old booteazy off a backup
before my system would boot again.
I have booteasy on dsk0, and used fdisk -b on dsk1 after installing hte
new bootblocks (3stage). It stopped booting and nothing I could do woul
dmake it boot
Mike Smith wrote:
The only configuration which currently works correctly is to remove the
kldload of the pcic module from /etc/rc.pccard and compile everything
else statically into the kernel.
Every other variation is *broken*.
Nope. I am kldloading pcic on my Libretto with no problems
Mike Smith wrote:
The only configuration which currently works correctly is to remove the
kldload of the pcic module from /etc/rc.pccard and compile everything
else statically into the kernel.
Every other variation is *broken*.
Nope. I am kldloading pcic on my Libretto with no
Mike Smith wrote:
Mike Smith wrote:
The only configuration which currently works correctly is to remove the
kldload of the pcic module from /etc/rc.pccard and compile everything
else statically into the kernel.
Every other variation is *broken*.
Nope. I am kldloading
The pcic module contains a reference to a symbol that's only present in
the kernel when the card* devices are statically compiled in. Ie. if
you remove pcic* and card* you can't load the pcic module.
I have card* compiled in (perhaps I should have mentioned that?), and
pcic*
24 matches
Mail list logo
