Re: [9fans] using plan 9 libraries on unix

["Russ Cox" <rsc@swtch.com>]

> How does one the use Plan 9 libraries under Linux
> after installation in /usr/local/Plan9?

I'm assuming you built and installed them (see /usr/local/plan9/NOTES).

In your environment set

	PLAN9=/usr/local/plan9 export PLAN9
	PATH=$PATH:/usr/local/plan9/bin export PATH

Then you'll have 9c, 9a, 9l, and 9ar that are
shell scripts around the system tools to make
them behave mostly like the Plan 9 tools.

So

	cat >x.c <<EOF
	#include <u.h>
	#include <libc.h>

	void
	main(void)
	{
		print("hello, world\n");
	}
	EOF
	9c x.c
	9l x.o
	./a.out

You can use mkfiles too, with minimal changes.
Instead of </$objtype/mkfile use <$PLAN9/src/mkhdr
and instead of </sys/src/cmd/mkone use <$PLAN9/src/mkone.
Ditto for mkmany, mksyslib.

<u.h> is an empty file, but <libc.h> (really <lib9.h>)
does not play nicely with the other headers.  It #defines
a few things to make the compilation world look
like Plan 9.  If you want to include other system
headers, you're likely to have to

	#define NOPLAN9DEFINES
	#include <u.h>
	#include <libc.h>
	#include <other headers>

and then put p9 at the beginning of calls to the various
renamed functions (e.g., p9wait, p9dup, p9open).
I am not happy with this, but there's no easy
way around it.  At some point I might shift things
around so you can say

	#include <u.h>
	#include <other headers>
	#include <libc.h>

The problem with doing that now is that libc.h defines
things like _POSIX_SOURCE and _BSD_SOURCE, which cause
headers like <sys/types.h> to behave differently.
If the other headers have already included <sys/types.h>
then when libc.h includes it, it will be a no-op and
not set things up as expected.  If I move all the _POSIX_SOURCE
and such into <u.h> then the above example would work.
In general I don't mix these in the same file (except
in the implementation of lib9) so it's not an issue.

Russ