We've been way to sloppy with /lib and /sys/lib to the point of the
distinction being almost meaningless.

In the case of libraries that are architecture dependent, the general
idea is to link them under their architecture's tree.  In  the manner
of $home/bin/{386, mips, ...} you can have a $home/lib/{386, mips, ...}
and in your lib/profile:

	for(i in 386 mips ...)
		bind -b $home/lib/$i /$i/lib

That way they'll be in the right place for {8, v, ...}l to find them.
Of course, if you put pragma's in the .h's for the libraries that point
to the libraries, you don't have to link them anywhere in particular.
However, the above might make life easier for you in the long run since
you can override just by binding.

If the libraries are also language dependent and the linking convetions
are different than those of C (or the names clash), you can have a
second level just as we do in /386/lib/alef, e.g.:

	for(i in 386 mips ...)
		bind -b $home/lib/$i/alef /$i/lib/alef

In the end, the only important thing is that the pragma's in the
include files point to the right place:

	#pragma	lib	"alef/libxyzzy.a"

The path is relative to /$objtype/lib.