Subject: Re: mopd and byte order
To: Blaz Zupan <blaz@inlimbo.org>
From: Maciej W. Rozycki <macro@ds2.pg.gda.pl>
List: port-pmax
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,
Too bad.
> "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)
Or:
$(CC) $(CFLAGS) $(LDFLAGS) -o mopd $(OBJS) $(LIBS) $(LIBELF)
actually.
> 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:
>
> 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.
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.
Excellent.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +