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        +