>  Hmm, using "@" and "^" variables in explicit rules is elegant but risky,
> otherwise I can't see any problems -- any standard make should do.  Moving
> "-lelf" last is probably a good thing to do.  Do the problems persist if
> the following patch is applied?

No, it still does not compile with this patch, also you have a typo in it,
"LIBELF=$(LIBELF) is missing the terminating quote. Also I needed to add
-I/usr/local/include to the CFLAGS and -L/usr/local/lib to the LDFLAGS for
obvious reason (libelf is installed in /usr/local).

After patching with your mopd-make patch, the mopd/Makefile looks like this:

mopd: $(OBJS) $(LIBS)
        $(CC) $(CFLAGS) $(LDFLAGS) $(LDADD) -o mopd $(OBJS) $(LIBS)

It should look like this to make it link on NetBSD:

mopd: $(OBJS) $(LIBS)
        $(CC) $(CFLAGS) $(LDFLAGS) -o mopd $(OBJS) $(LIBS) $(LDADD)

Another problems is, that you only declare the "promisc" variable as extern,
so it fails on the link stage. The following patch fixed it for me:

--- common/pf.c.orig   Sat Mar  2 22:50:34 2002
+++ common/pf.c        Sat Mar  2 22:50:50 2002
@@ -67,7 +67,7 @@
  */

 extern int errno;
-extern int promisc;
+int promisc = 1;

 /*
  * Return information to device.c how to open device.

>  I didn't touch system-specific code I couldn't test -- the conditional
> clause looks weird indeed; it's probably a bug workaround.  Does it work
> if you change "#if !defined(__FreeBSD__)" into "#if 1"?  It would be good
> to know which version of FreeBSD the workaround is not needed from and how
> to detect it in the preprocessor.

It is indeed. Only after already giving up on mopd on FreeBSD I found the
following patch. You may want to add this to your mopd patch collection:

ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports-current/net/mopd/files/patch-put.c

The some directory contains some other patches, I don't claim to understand
what they do.

>
> > compile it by myself, which didn't work out of the box. The following patch
> > fixed the libelf compile on NetBSD:
> [...]
> > -for ac_hdr in unistd.h fcntl.h elf.h sys/elf.h link.h sys/link.h
> > +for ac_hdr in unistd.h fcntl.h sys/elf.h link.h sys/link.h
>
>  Weird -- is there anything wrong with <elf.h> on NetBSD?  Anyone could
> comment?

Yes, the problem is, that it is missing a lot of data. libelf assumes that if
it finds elf.h, it will find all the definitions it needs there. So it fails
during the compilation phase because of a lot of missing definitions. If it
doesn't look for the elf.h file, it uses its own lib/elf_repl.h file which
contains the neccesary definitions. A prime example is EI_NIDENT, which is
defined in elf_repl.h, but not in /usr/include/elf.h.

> > Unfortunatelly it hung at exactly the same place as the diskboot. So I'm
> > giving up on NetBSD.
>
>  Do you mean it started at all?  If so, it's nice this patched mopd may be
> useful for NetBSD as well.  Too bad the kernel hung on your system, but I
> cannot help you with that, sorry -- someone else here probably could.

Yep, it started just fine and booted up to the point where it always hangs for
me - after detecting the SCSI controller. On a machine where a netbsd kernel
works, mopd would now probably be able to fully boot it.