Subject: Re: mopd and byte order
To: Blaz Zupan <email@example.com>
From: Maciej W. Rozycki <firstname.lastname@example.org>
Date: 03/04/2002 14:09:49
On Sat, 2 Mar 2002, Blaz Zupan wrote:
> 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
Thanks and sorry for the inconvenience -- the patch was untested.
> -I/usr/local/include to the CFLAGS and -L/usr/local/lib to the LDFLAGS for
> obvious reason (libelf is installed in /usr/local).
You should use:
$ make "CFLAGS=-I/usr/local/include" "LDFLAGS=-L/usr/local/lib"
to circumvent it. You may add arbitrary flags this way (e.g. I override
CFLAGS with "-pipe -O2 -fomit-frame-pointer" usually; CC is overrideable
as well). Default Makefiles should work just fine whan all libraries are
in places normally seen by a compiler -- surely one cannot foresee all
possible library locations.
> mopd: $(OBJS) $(LIBS)
> $(CC) $(CFLAGS) $(LDFLAGS) -o mopd $(OBJS) $(LIBS) $(LDADD)
$(CC) $(CFLAGS) $(LDFLAGS) -o mopd $(OBJS) $(LIBS) $(LIBELF)
> 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:
> extern int errno;
> -extern int promisc;
> +int promisc = 1;
The variable has been renamed to "nomulti" -- you only need to enable the
all-multicast mode if an interface is unable to set up a multicast filter.
Using the promiscuous mode is an overkill -- surely you don't want to
handle the whole traffic only to drop most of the received frames.
> 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.
Thanks -- I'll look at them.
> > > -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
Hmm, the contents of <elf.h> is pretty well defined by the ELF ABI. It
is a misery someone got this header wrong.
> 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.
I'll look at what needs to be checked for a proper validation. EI_NIDENT
is quite critical, actually, as the file header definition depends on it.
> 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.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +