[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 15 Feb 2010 08:41:14 -0500
I tried doing a build on my Mac (running 10.6.2) this morning, and ran into
#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
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....
- build problems,
Ken Raeburn <=