[OLSR-users] olsr-0.5.0 with OpenBSD 4.0 compile problems
Mon Apr 30 18:26:37 CEST 2007
> > First error: Bison refuses to generate parse.c
> Funny, bison-1.35 and bison-1.875d have no problem with it.
Interestingly enough, the linux host has bison 2.1, and it parsed
Ran the command: bison -v -ooparse.c oparse.y
To double check... see nothing weird in the oparse.c.output parse log
(but I'm definitely no bison expert)
> > Second error:
> > cc -DVERSION=\"0.5.0\" -MD -Isrc -I./src -D__OpenBSD__ -c -o
> > src/bsd/net.o src/bsd/net.c
> > src/bsd/net.c: In function `set_sysctl_int':
> > src/bsd/net.c:141: warning: passing arg 4 of `sysctl' from
> > incompatible pointer type
> > src/bsd/net.c: In function `get_ipv6_address':
> > src/bsd/net.c:538: error: storage size of `ifr6' isn't known
> > src/bsd/net.c:549: error: dereferencing pointer to incomplete type
> > src/bsd/net.c:551: error: dereferencing pointer to incomplete type
> > src/bsd/net.c:552: error: dereferencing pointer to incomplete type
> > src/bsd/net.c:554: error: dereferencing pointer to incomplete type
> > src/bsd/net.c:564: error: `SIOCGIFAFLAG_IN6' undeclared (first use in
> > this function)
> > src/bsd/net.c:564: error: (Each undeclared identifier is reported only once
> > src/bsd/net.c:564: error: for each function it appears in.)
> > src/bsd/net.c:572: error: `IN6_IFF_ANYCAST' undeclared (first use in
> > this function)
> > src/bsd/net.c: In function `olsr_recvfrom':
> > src/bsd/net.c:728: error: storage size of `iov' isn't known
> > gmake: *** [src/bsd/net.o] Error 1
> That needs a patch from the "BSD world". I have no access to *BSD ...
I could probably assist in finding the appropriate struct's and
whatnot, but I'm not in much of a position to test ipv6 code.
Adding these to src/bsd/net.c seems to fix the problem, and I now have a binary:
#include <netinet6/in6_var.h> /* For struct in6_ifreq */
cc -DVERSION=\"0.5.0\" -static -MD -Isrc -I./src -D__OpenBSD__ -c
-o src/bsd/net.o src/bsd/net.c
src/bsd/net.c: In function `set_sysctl_int':
src/bsd/net.c:144: warning: passing arg 4 of `sysctl' from
incompatible pointer type
if (sysctl(mib, 4, &old, &len, &new, sizeof (new)) < 0)
As for this one, len is an unsigned int.... OpenBSD expects a size_t like MacOSX
At the beginning of set_sysctl_int:
#if __MacOSX__ || defined __OpenBSD__
size_t len = sizeof (old);
unsigned int len = sizeof (old);
I added the || OpenBSD, which gets rid of the warning.
> > Next, I was left with the iov size error... after a quick grep of
> > /usr/include, I found it referenced in sys/uio.h.
> > I added in the OpenBSD include section:
> > #include <sys/uio.h>
> In bsd/src/net.c (if I understand it correctly)?
> I can add that without patch;-)
Heh, yeah.. That is correct. (well.. src/bsd/net.c anyway) :)
> > src/link_set.o(.text+0x6dc): In function `add_new_entry':
> > : warning: strcpy() is almost always misused, please use strlcpy()
> Yes, that's (and similar things) on my cleanup list. I'm more thinking
> on using snprintf() since that seems to be more widespread available.
> But I have no strong feelings for this.
> FWIW I ran olsrd compiled with a bounds-checking-patched gcc
> (http://sourceforge.net/projects/boundschecking/ - alas, only 4.0.2 is
> the most recent) for months (0.4.9 + patched versions) and it never hit
> a buffer overrun AFAICT. However, there are statically sized buffers in
> there which are filled and - judging from the function in question only
> - may overrun.
I'll probably want to do some code auditing (for overflow) at some
point here, but that's encouraging news.
Here's the strcpy:
Which I think should be:
strlcpy(new_link->if_name, local_if->int_name, sizeof(new_link->if_name));
Of course, compiling that just exposed another strcpy (in
Anyway.. I'll visit that soon.
> > I am however experiencing regular messages as above, stating that its
> > trying to send packets to an unreachable network. I suspect this is
> > not serious, however intend to investigate soon.
> Yes, suchh error messages also an open/uninvestigated issue on Linux.
> But AFAICS everything works .....
I suspect it's trying to send packets to someplace it shouldn't. I'll
have a look at this later too.
More information about the Olsr-users