Thank you for your feedback, François. We have now put the port in Git ( and our changes should all be in the branch 'plan9'. We are next about to rebase our branches onto 'head' instead.

> Does it require C89 style (like, variables declared at beginning of block)?

The compilers in 9front has partial C99 support, including support for variable declaration anywhere in the block, and we'd consider adding needed features for better compliance, if needed.

If to merge the Plan 9 port into the upstream later, maybe a solution would be to have a 'mkfile' fragment that lists sources, one per line. That could be included by both gmake and mk:

-- mkfile --

OFILES=`{<files grep '\.c$' | sed 's/c$/$O/g'}

-- gmake --

DIR_SOURCES=$(shell cat files)

The main things we had to do to compile:

* libwapcaplet has macros that uses GNU extensions, that would require 'statement expression' support in the compiler. Maybe these functions could be made 'static inline' instead, as is used in other places.

* copied a number of auto generated files from a Linux build, generated by Perl, Python, Flex & Bison. We'll need to update 'ports' (our imported tools and libraries) if we want a fully native build, that's on us. Haven't tried the available ports of Perl & Python in Plan 9, but the .l and .y didn't work with the original Lex and Yacc.

* we need C99 macro varargs, (...) and __VA_ARGS__, instead of the non-standard GCC macro varargs (...args).

* our compiler currently doesn't support bitfields in static initialisers. We'd like to fix this eventually, but for now we just changed bitfields to shorts and integers.

* we don't have support for variable length arrays (VLA) on the stack (e.g. widths[][] and heights[][] in netsurf/desktop/frames.c)

Lastly, here is a video clip showing how downloading and running looks now: (7 min)


On 8 January 2020 at 17:52:07 +02:00, François Revol <> wrote:
Hi Jonas,

Le 06/01/2020 à 16:38, Jonas a écrit :
Dear Netsurf developers,

I have started a port of Netsurf 3.9 to the operating system Plan 9
(, It uses the framebuffer
frontend for now, but I plan to continue with a native frontend, also
possibly with help from other developers.

Wow, nice to see NS ported to yet another platform :-)

quality of the Netsurf source. Another obstacle is that most larger GNU
development tools aren't available for Plan 9, no GCC for example. Plan
9 has its own C compiler ( that
sometimes does things in different ways, and typically doesn't support
GCC extensions and newer features added to the language lately.

Does it require C89 style (like, variables declared at beginning of block)?

For the Haiku ports I tried to maintain C89 code for a while for GCC
2.95, and if another platform requires it that'd be an incentive to fix
replicant support so we could put NS as a widget on the desktop…

In the absence of GCC/Autotools/GNUmake and friends, I have written my
own build system using Plan 9 'mk' (using 'mkfile'). I am aware that
this makes a possible upstream integration of the port harder.

Well we don't use autotools anyway, we have custom makefiles used as a
buildsystem for all libraries:

Maybe it's possible to isolate the incompatible parts from it and
reimplement them for other make engines?

I once managed to write a simple makefile engine for both GNU make and
MS Nmake that accepted unchanged makefiles with only declarative stuff:

Alternative routes would have been making GCC work on plan 9---some work
has been done on this (, or to try to generate
plan 9 binaries from Linux using cross compilation. Both ways would be a
lot of compiler development work, and I am quite sure that the plan 9

Well for continuous integration we might want to do that anyway. But if
you went this far without changing code it can probably be fixed.

I started with the source tree of Netsurf 3.9, downloading all all
support libraries separately (that is why they have version numbers in
the directories). I have not deleted any files, only added files and
changed files. All files 'xxx.y' that I changed are backed up as
'orig_xxx.y' making it easier to 'diff' against the original. I got the
tip that it might be a good idea to make a clone of the official Git
repository and applying the diffs against it, in which case the 'orig_'
files won't be necessary, and a possible merger maybe easier to do in

Indeed, it's usually better to work on the HEAD. And with git you can
rebase your changes from time to time, with git resolving most of the
conflicts itself.

I believe you should already have a git client:

It might also be possible to build some simple client like this one
using libgit2: