> > 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* k
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*.
> >
> >
> 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 Lib
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 prob
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 b
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 kerne
> 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
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 c
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
follow
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
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
> 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 t
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 `unregister_pcic_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 `regis
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
re
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 -DVM_STA
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 bootea
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
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
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
> /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
> > 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
ma
> 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 o
>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 weir
24 matches
Mail list logo
