Errors when building on FreeBSD

[krrrcks]

I followed #7 and produced the boot files for 'a6fb' on my 64bit Linux machine. After that I copied them to my FreeBSD machine which is "FreeBSD 11.0-RELEASE-p8" running as a VM. After configure I started the build process by gmake and when compiling prim5.c I got these error messages:

gcc  -Wpointer-arith -Wextra -Werror -O  -c -DX86_64 -I../boot/a6fb -I../zlib -I/usr/local/include -I/usr/X11R6/include prim5.c
prim5.c: In function 's_iconv_from_string':
prim5.c:1984:22: error: passing argument 2 of 'libiconv' from incompatible pointer type [-Werror=incompatible-pointer-types]
   ICONV((iconv_t)cd, (ICONV_INBUF_TYPE)&inbuf, &inbytesleft, &outbuf, &outbytesleft);
                      ^
In file included from prim5.c:1897:0:
/usr/local/include/iconv.h:85:15: note: expected 'char **' but argument is of type 'const char **'
 extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
               ^
prim5.c: In function 's_iconv_to_string':
prim5.c:2015:22: error: passing argument 2 of 'libiconv' from incompatible pointer type [-Werror=incompatible-pointer-types]
   ICONV((iconv_t)cd, (ICONV_INBUF_TYPE)&inbuf, &inbytesleft, &outbuf, &outbytesleft);
                      ^
In file included from prim5.c:1897:0:
/usr/local/include/iconv.h:85:15: note: expected 'char **' but argument is of type 'const char **'
 extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
               ^
cc1: all warnings being treated as errors
gmake[2]: *** [Makefile:30: prim5.o] Error 1
gmake[1]: *** [Makefile:20: build] Error 2
gmake: *** [Makefile:19: build] Error 2

This seams to be different to #143, but as @gwatt mentioned in https://github.com/cisco/ChezScheme/issues/143#issuecomment-284274115 he faced the same problem when building on FreeBSD.

As I am not a C programmer I have no clue on how to fix it or provide a PR that smooths these things.

[bnoordhuis]

Try updating the ICONV_INBUF_TYPE define for your machine. It's const char ** now but the error suggests it should be char **. It's this block in c/version.h.

[krrrcks]

Thanks for the hint. After changing that I built without any problems. I ran the make test suite which when well except some entries in summary of this kind:

-------- o=0 --------
0a1,8
> foreign.mo:Error in mat load-shared-object clause 3: "(while loading libc.so) /usr/lib/libc.so: invalid file format" at line 183,
char 7 of foreign.ms
> foreign.mo:Error in mat varargs clause 2: "separate-eval: Exception: (while loading libc.so) /usr/lib/libc.so: invalid file format
 " at line 2595, char 3 of foreign.ms
> foreign.mo:Error in mat varargs clause 3: "separate-eval: Exception: (while loading libc.so) /usr/lib/libc.so: invalid file format
 " at line 2605, char 3 of foreign.ms
> foreign.mo:Error in mat varargs clause 4: "separate-eval: Exception: (while loading libc.so) /usr/lib/libc.so: invalid file format
 " at line 2615, char 3 of foreign.ms
> foreign.mo:Error in mat varargs clause 5: "separate-eval: Exception: (while loading libc.so) /usr/lib/libc.so: invalid file format
 " at line 2625, char 3 of foreign.ms
> 5_3.mo:Bug in mat expt clause 9 at line 2321, char 5 of 5_3.ms
> misc.mo:Bug in mat sci-bug clause 1 at line 3327, char 3 of misc.ms
> misc.mo:Bug in mat sci-bug clause 2 at line 3328, char 3 of misc.ms

[akeep]

I put in a fix (1de3815) that addresses the foreign.mo bug. (Unfortunately, the date on my VM was incorrect, so it looks like it came in 3 days ago... sorry about that.)

The 5_3.mo and misc.mo bugs are known bugs with the math library on FreeBSD. I took a look into this, and in all three cases the problem is around the pow C function. In prim5.c the pow function is special cased for i3fb and ti3fb. I tried extending this for a6fb and ta6fb. Essentially, the problem seems to be that we get a result that is slightly off from what we expected. (expt 10.0 -20.0) yields 1.0000000000000001e-20 instead of 1e-20.

This may be fixable, but it is going to take a bit more investigation to figure out what is going on.

[mflatt]

Is this still an issue? It looks like there are commits to address the problem.