build problems

[Ken Raeburn]

I tried doing a build on my Mac (running 10.6.2) this morning, and ran into 
some problems.

#1: c-tokenize.lex declares yyget_leng() as returning int, but the flex 
template defines it as returning yy_size_t (which is size_t, a.k.a. unsigned 
long), so c-tokenize.c doesn't compile.  Changing the declaration in 
c-tokenize.lex to return size_t works for me, but the file hasn't been changed 
in some time, so if "int" was working for other platforms, changing it could be 
a problem.

We don't actually reference yyget_leng elsewhere explicitly; can we just get 
rid of the declaration?

#2: I build outside the source tree, with "../relative/path/to/configure 
--prefix=whatever ...", and make-texinfo.scm was failing for me.  After some 
time chasing things down with the debugger (thanks Andy for reminding me to 
recompile to get debug info) and the moral equivalent of debugging printfs, I 
found that load-module in boot-9.scm tries to interpret a relative path as 
relative to the filename for the current-load-port, if there is one.  Since the 
currently loading file was "../../../doc/ref/make-texinfo.scm" and the supplied 
filename (given on the command line) was 
"../../../doc/ref/standard-library.scm", load-module jammed the two prefixes 
together and came up with a pathname pointing off to nowhere.

Changing Makefile.am to remove the "$(srcdir)" prefix works around this, though 
I can't help but think there may be other potential cases where a relative path 
*not* coded directly in the loading module itself may be intended to be 
relative to the current directory and not the loading module's directory.

#3: Okay, I finally got to "make check", and two getaddrinfo tests failed, 
which Ludo and Andy were talking about on IRC.  I think these are bugs in the 
tests.  It appears that one ("wrong service name") is looking for EAI_SERVICE, 
when I think EAI_NONAME is the correct error to be returned in that case, or at 
least an acceptable error.  In the other ("port 80"), if I read it right, it's 
looking for AI_ADDRCONFIG to be set in the returned flags?  I don't think 
that's guaranteed at all.

#4: Looking at the doc for getaddrinfo, AI_ADDRCONFIG is described as returning 
"only addresses configured on the local system."  I think that should be "only 
address families...."  Clearly, if you're looking up the address of some 
server, you don't want your query to return only your own addresses.

Patches coming later, maybe, after work, if no one else gets to them first....

Ken