Subject: Re: mopd and byte order
To: Maciej W. Rozycki <firstname.lastname@example.org>
From: Blaz Zupan <email@example.com>
Date: 03/02/2002 22:55:08
> 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:
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
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.