>> touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want.
>
> if you are trying to boot from a fossil root and do this,
> your kernel will not be able to successfully mount the root
> filesystem.
>
> don't do this if you expect to boot.
Only if there was no /386/bin/fossil/fossil b
> Bob,
>
>> mk: don't know how to make '/386/bin/fossil/fossil' in directory
>> /sys/src/9/pc
>
> touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want.
if you are trying to boot from a fossil root and do this,
your kernel will not be able to successfully mount the root
filesystem.
Bob,
> mk: don't know how to make '/386/bin/fossil/fossil' in directory
> /sys/src/9/pc
touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want.
Hope this helps,
Jerome Ibanes
> what i know is
> a) it build just fine on my system, but i don't use pull.
> b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x
> so that there's a mk rule like so "%.8: %.$x", i get the following
> error message
> ; mk xyzw.8
> mk: no recipe to make 'xyzw.8' in directory /
I have a long term project to get somthing like p9p running under windows
though my goal is to use a windows box as a plan9 cpu server so /dev/draw
is not a priority.
My approach is very similar to Russ's p9p for windows alpha on swtch.com
but it is many months away from finished - i get a day a w
dt can be compiled using either mingw or ms tools. might want to read
rsc's recent post about 9vx port to windows and the relative ease
compared to porting p9p.
>>could p9p possibly compile and run under Cygwin?
>
> Might be an easier port... MinGW might be preferable, as drawterm uses it,
> an
>could p9p possibly compile and run under Cygwin?
Might be an easier port... MinGW might be preferable, as drawterm uses it, and
again might be easier...
Neither would work out of the box, though.
>An extra of indirection may not be the most efficient thing, but...
My approach thus far has been
Benjamin Huntsman wrote:
might it be more straightforward to modify the plan9port sam to run on 9pm, or
would the only way to get it running on Windows be to port the whole lib9 from
p9p at the same time?
... I hate Windows, but alas, it's what I have to live with for my job ..
Here is a
is anyone on the list running plan 9 on an amd k10
natively? or even emulated?
- erik
As far as I could find, there isn't a newer version of sam for Windows then the
one from 9pm, so I started trying to port the plan9port version. So far, I got
all of the stuff in the sam/ directory to compile.
I'm stuck on lib9, though, since it doesn't compile on Windows in its current
form.
9,
>> mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip
> does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an
> error in the pull database on sources. you can copy it
> by hand with
> 9fs sources && cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c
> /sys/src/cmd/ip/
> Eri
> Erik, it already exists and has the same MD5 checksum than the one in
> sources.
i'm fresh out of ideas, then.
what i know is
a) it build just fine on my system, but i don't use pull.
b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x
so that there's a mk rule like so "%.8: %.$x", i
9,
>> mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip
> does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an
> error in the pull database on sources. you can copy it
> by hand with
> 9fs sources && cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c
> /sys/src/cmd/ip/
Erik
> I'm having the same exact issue with a July 19th iso.
>
>>> this would be expected due to the pull which sets the mtimes of
>>> new files to be older than the .8s. try "mk clean" before proceeding.
>> So, now in /sys/src I do
>> mk cleanok,
>> mk allfails with
>>
9,
>> Something not quite right with my system??? It's from the plan9 iso
>> dated June 26th..
I'm having the same exact issue with a July 19th iso.
>> this would be expected due to the pull which sets the mtimes of
>> new files to be older than the .8s. try "mk clean" before proceeding.
> So,
>> by "work" you mean not generate an out-of-range
>> memory access nor not produce unexpected values?
>>
>> - erik
>
> i meant "pass muster", which i thought was the sense originally
> intended (ie, link without diagnostic) but i see now that wasn't intended.
> sorry.
>
> anyhow, that's why it
Hi!
I'am new to 9vx/p9p and try to configure /net.
# uname -a
FreeBSD r60e 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Wed Jul 9 17:33:56 UTC 2008
gonzo@:/usr/obj/usr/src/sys/GENERIC i386
% bind -b '#I' /net
% ip/ipconfig -g 192.168.0.1 ether /net/ether0 192.168.0.32 255.255.255.0
ipconfig: no ip
>> not exactly. it will work on most Unix systems and
>> on Plan 9 without -T because nothing checks
>> external types across object module boundaries. the linker/loader in both
>> systems
>> will allocate in BSS the largest size seen for a given symbol,
>> so it doesn't matter whether int == lon
There have been several discussions on this list about 9vx's
IP stack being different from "normal" Plan 9 in the last two
weeks; you should check those out. The short version is that
9vx uses the host networking rather than its own, and (more-
or-less) consequently the kernel device presents a mor
erik quanstrom wrote:
Ok. I pulled and remade fossil which got over that error. But now I do
mk 'CONF=pcf' and get
size 9pcf
links: incompatible type signitures ..(for a whole load of init
files ie tcpinit, udpinit etc)
and then
mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc
> not exactly. it will work on most Unix systems and
> on Plan 9 without -T because nothing checks
> external types across object module boundaries. the linker/loader in both
> systems
> will allocate in BSS the largest size seen for a given symbol,
> so it doesn't matter whether int == long or n
> it will work perfectly if the -T flag is not
> given (since there is a deep assumption
> in plan 9 that int == long). but i the
not exactly. it will work on most Unix systems and
on Plan 9 without -T because nothing checks
external types across object module boundaries. the linker/loader in bo
> this would be expected due to the pull which sets the mtimes of
> new files to be older than the .8s. try "mk clean" before proceeding.
i should explain that type signatures are 32-bit
signatures in .$O files that define the type of
external symbols. the c compiler sets the type
signature to z
> Ok. I pulled and remade fossil which got over that error. But now I do
> mk 'CONF=pcf' and get
>
> size 9pcf
> links: incompatible type signitures ..(for a whole load of init
> files ie tcpinit, udpinit etc)
>
> and then
>
> mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc 1887:
erik quanstrom wrote:
I am having trouble building a new kernel for a terminal.
I do
mk 'CONF=pcf'
and I get the error
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
does /386/bin/fossil/fossil exist? if not, it's a little
worrying that it does
Thank you both for your infromative replies.
A 'mk all' in /sys/src/cmd gave errors so I am doing a pull now
Bob
> I am having trouble building a new kernel for a terminal.
> I do
>mk 'CONF=pcf'
> and I get the error
>
> mk: don't know how to make '/386/bin/fossil/fossil' in directory
> /sys/src/9/pc
does /386/bin/fossil/fossil exist? if not, it's a little
worrying that it doesn't. perhaps th
The kernel mkfiles don't know how to build dependencies from
the cmd tree. The mk you're doing knows fossil is missing or out
of date, but not how to do anything about it. Build it yourself. I
mk all of /sys/src/cmd to be safe, but you could just hit the list
you need for your kernel (whatever file
Hi all,
I am having trouble building a new kernel for a terminal.
I do
mk 'CONF=pcf'
and I get the error
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
A
mk 'CONF=pc'
works fine.
I am hoping this is some simple newbie mistake.
Thanks
Bob
On Tue, Jul 22, 2008 at 11:50 PM, Charles Forsyth <[EMAIL PROTECTED]> wrote:
>> no adding very large amounts of code... maybe fix the swap... or even
>> remove it alltogether.
>
> assuming it doesn't work now, the paging code used to work, at least
> in the sense of survive --i used 8l to link kern
> no adding very large amounts of code... maybe fix the swap... or even
> remove it alltogether.
assuming it doesn't work now, the paging code used to work, at least
in the sense of survive --i used 8l to link kernels on a 4mbyte 386sx16 --
so i imagine it's just a matter of repairing it, if it in
> the alternative is to add very
> large amounts of code to the kernel.
not really. the alternative is to add some code to the
kernel, and varying amounts of code to quite a few applications.
> Swap doesnt work reliable here. :-(
> I have disabled swaping and let the kernel kill the biggest process
> skipping any critical server processes and it works well.
> got ~100 days uptime and i use this machine for linuxemu
> development/testing.
i'm curious as to what is taking so much memory.
sqweek wrote:
On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
Also, public 9grids. Though judging by gdiaz's experiences with
sirviente, there's a bit of work to be done in that area - I get the
impression things are fairly unstable once the machine gets under
memor
On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> Also, public 9grids. Though judging by gdiaz's experiences with
>> sirviente, there's a bit of work to be done in that area - I get the
>> impression things are fairly unstable once the machine gets under
>> memory pressu
35 matches
Mail list logo
