gillhaa@ghost.whirlpool.com said:
>  but make is still wrong when it looks for the file dependencies to
> build.  I am 100% certain of that. Otherwise, a hung /net mount would
> never hang a make at "checking libcompat" in 'netio' or similar. 

You are right, there is something inconsistent in the
make process if relative paths and "obj" dirs (or "MAKEOBJDIR" in this
case) are used together.

What happens is probably the following:
"make depend" takes place in .OBJDIR, and if it got passed
relative paths it will list all these dependencies relative
to .OBJDIR.
"make" for itself will look for files something depends on
first relative to the source (which is sys/compat/common here),
then along the .PATH and lastly in .OBJDIR.
So it happens that a lookup for eg ../../../../../../net/radix.h
takes place from /usr/src/sys/compat/common, which rams hefty
into the root dir and comes out as /net/radix.h.

I see 2 ways out:
a) Pass absolute search paths to "mkdep" or paths relative
   to sys/compat/common. The latter is hard because it would have
   to be constructed from the kernel build dir which is variable.
   The former is not desirable for the reasons mentioned in the
   other mail.
b) Don't "cd" to sys/compat/common but call the submake as "make -f ..."
   from the library build dir. Use .PATHs to find the source files.
   This looks like a major undertaking.

Hmm, perhaps "make" could be tought to ignore .CURDIR and .PATH
for dependencies in .depend files. Or some "make" attributes
like .NOPATH could be used?

Toolchain experts there?

best regards
Matthias