Jens Staal dixit:

> On the other hand, that would disable it for all compilers on Plan9 (there is
> also an old gcc 3.0 port...). I think having a special ct=plan9 could catch
> those special issues when the native ape/cc is used (making a rule with no -O
> and no -W stuff).

Indeed. It’s, of course, a bit tricky to actually detect it.

> ah sorry. it should be the first line. The error message is:
>
> "array size must be a positive constant"

That’s true for *all* of them ;-)

One of the conditions (“cta” in the source) is untrue.

> In the attached patch, I do work around it since I don't understand the stuff.

Please resend as unidiff (“diff -up” or, if -p doesn’t work in your
diff(1) utility, at least “diff -u”).

> I am an amateur so much of what I do is horrible :)
>
> There is most likely a much nicer solution to this problem.

We’ll see ;-) but first I need to have a legible patch ☻

> Attached is a patch to Build.sh. I put the tests for "PLAN9" last in the
> compiler tests in the hope that (gcc and hypothetical) alternative compilers 
> on
> Plan9 then would have a chance first.

That’s probably a good idea.

> I had to re-define setegid and seteuid to setuid and setgid - a problem?

Their semantics (under Unix) differ. If Plan 9 does not distinguish
between a real uid/gid and an effective uid/gid, -DMKSH__NO_SETEUGID
like BeOS does.

> With the attached patch (done with the Plan9 "diff -n"), mksh builds with the

Aieee. There we seem to have a reason…

> native "cc" compiler under Plan9 APE using Build.sh.

We do need the APE cc front-end, not the native kencc, because
we do require an ANSI C præprocessor. But that’s nomenclature.

> The resulting binary can execute and within the shell, one can execute an
> external command (I tried "lc") once but it does not go back to being ready 
> for
> a new command (I tried killing "lc" with the Del key or ctrl-c).

That’s known: add -DMKSH_NOPROSPECTOFWORK to get something that
closely resembles a working mksh, *but* lacks some fundamental
functionality and *will* hang some of the regression tests (those
marked “nojsig”).

In Haiku, the same problem existed but was confirmed to be a
kernel bug; see the mksh website for a link to the bug tracker
entry. In Syllable Desktop and Plan 9, this problem is unsolved,
but we assume it’s, similarily, a bug in signal delivery in the
POSIX compatibility code.

And the mksh-to-native-WinAPI porter has run into the same problem
(and is working on a solution that doesn’t involve a full POSIX
layer but only “enough to get mksh to work on WinAPI”).

bye,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt

Reply via email to