From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: build problems Date: Mon, 15 Feb 2010 08:41:14 -0500 Message-ID: <2464F0C7-8A6F-4249-A68F-21757F5E6862@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1266241397 4650 80.91.229.12 (15 Feb 2010 13:43:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Feb 2010 13:43:17 +0000 (UTC) To: Guile Development Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 15 14:43:15 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nh1EI-0003Wm-F9 for guile-devel@m.gmane.org; Mon, 15 Feb 2010 14:43:14 +0100 Original-Received: from localhost ([127.0.0.1]:55282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nh1EH-0002G6-Vr for guile-devel@m.gmane.org; Mon, 15 Feb 2010 08:43:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nh1CX-0001MI-7g for guile-devel@gnu.org; Mon, 15 Feb 2010 08:41:25 -0500 Original-Received: from [140.186.70.92] (port=37813 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nh1CW-0001Lo-Jv for guile-devel@gnu.org; Mon, 15 Feb 2010 08:41:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nh1CV-000556-Hc for guile-devel@gnu.org; Mon, 15 Feb 2010 08:41:24 -0500 Original-Received: from splat.raeburn.org ([69.25.196.39]:43527 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nh1CN-00054c-Pm for guile-devel@gnu.org; Mon, 15 Feb 2010 08:41:23 -0500 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o1FDfEQ0020437; Mon, 15 Feb 2010 08:41:14 -0500 (EST) X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9985 Archived-At: 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=3Dwhatever ...", 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=