Dear all,
I just hit the following compilation error and I wonder if this is some
sort of bug in the APE libraries and how to trace down what is really
wrong:
??none??: incompatible type signatures
50220469(/386/lib/ape/libdraw.a(screen)) and
9bbe58(/386/lib/ape/libbsd(bind)) for bind
htonl: inc
> I just hit the following compilation error and I wonder if this is some
> sort of bug in the APE libraries and how to trace down what is really
> wrong:
I had a similar situation when compiling the entire userland. I
hacked each as seemed appropriate, but somebody ought to go in there
with a sh
Erik's explanation certainly makes sense, but here's an
alternative possibility. In the past, I've set up the bios on
a system a certain way, then accidentally written to
#r/nvram (which isn't really useful on a PC), and had the
bios reset to factory defaults. Behavior of the bios after
writing th
On Mon, 19 Aug 2013 17:30:52 +0200
lu...@proxima.alt.za wrote:
> > I just hit the following compilation error and I wonder if this is
> > some sort of bug in the APE libraries and how to trace down what is
> > really wrong:
>
> I had a similar situation when compiling the entire userland. I
> ha
On Mon Aug 19 12:25:33 EDT 2013, a...@9srv.net wrote:
> Erik's explanation certainly makes sense, but here's an
> alternative possibility. In the past, I've set up the bios on
> a system a certain way, then accidentally written to
> #r/nvram (which isn't really useful on a PC), and had the
> bios
On Mon Aug 19 11:21:18 EDT 2013, staal1...@gmail.com wrote:
> Dear all,
>
> I just hit the following compilation error and I wonder if this is some
> sort of bug in the APE libraries and how to trace down what is really
> wrong:
>
> ??none??: incompatible type signatures
> 50220469(/386/lib/ape/l
it is possible that i could have built a new 9pccpuf after the initial boot
of the fs and installed it in place but had never rebooted the machine with
the new kernel; but (old age memory failings notwithstanding), i don't
think i did that.
FYI, i think i noticed that in ata compatibility mode vid
x=foo; @{x=bar}; echo `{cat /env/x}
yields "foo" but
x=foo; echo; @{x=bar}; echo `{cat /env/x}
yields "bar"
the problem is that the environment variables are
only flushed to /env on exec, but not on fork.
in the first example, after executing the
subshell, x is still marked as "modified" by
us
On Mon Aug 19 15:37:24 EDT 2013, cinap_len...@gmx.de wrote:
> x=foo; @{x=bar}; echo `{cat /env/x}
>
> yields "foo" but
>
> x=foo; echo; @{x=bar}; echo `{cat /env/x}
>
> yields "bar"
>
> the problem is that the environment variables are
> only flushed to /env on exec, but not on fork.
>
> in th
on races... normal forks will all share the /env environment but
not the in memory variables of rc. so when we would normally fork
whoever does an exec (flush) first will override what the values of the
/env variables are, *independent* of the variables that where
actually modified *in* the process
10 matches
Mail list logo