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: Re: build problems Date: Thu, 4 Mar 2010 03:25:09 -0500 Message-ID: <1A1A9169-418F-45BD-BDBD-30F580C4A9F8@raeburn.org> References: <2464F0C7-8A6F-4249-A68F-21757F5E6862@raeburn.org> <160CB0AA-BDD6-4EE8-B99E-9D75D288E55D@raeburn.org> <87635f3tue.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1267691166 13870 80.91.229.12 (4 Mar 2010 08:26:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Mar 2010 08:26:06 +0000 (UTC) Cc: guile-devel@gnu.org To: =?iso-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 04 09:26:01 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 1Nn6Nc-0002RM-Ii for guile-devel@m.gmane.org; Thu, 04 Mar 2010 09:26:01 +0100 Original-Received: from localhost ([127.0.0.1]:53264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nn6Nb-0003lx-2h for guile-devel@m.gmane.org; Thu, 04 Mar 2010 03:25:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nn6NB-0003em-DE for guile-devel@gnu.org; Thu, 04 Mar 2010 03:25:33 -0500 Original-Received: from [140.186.70.92] (port=57382 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nn6N9-0003eS-GM for guile-devel@gnu.org; Thu, 04 Mar 2010 03:25:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nn6N8-0007kK-4f for guile-devel@gnu.org; Thu, 04 Mar 2010 03:25:31 -0500 Original-Received: from splat.raeburn.org ([69.25.196.39]:41524 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nn6Mq-0007ik-3l; Thu, 04 Mar 2010 03:25:30 -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 o248P9oU028239; Thu, 4 Mar 2010 03:25:09 -0500 (EST) In-Reply-To: <87635f3tue.fsf@gnu.org> 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:10015 Archived-At: On Mar 2, 2010, at 05:23, Ludovic Court=E8s wrote: >>> We don't actually reference yyget_leng elsewhere explicitly; can we = just get rid of the declaration? >>=20 >> This patch has been working fine for me on my Mac; we may be able to = delete more of the declarations, depending what other lex = implementations do >=20 > Keep in mind that =91c-tokenize.c=92 is part of the distribution, so = we > shouldn=92t worry much about what Flex implementations do, as long as = the > file we ship compiles fine. True for most people (if they don't do things that cause timestamps to = randomly get updated, like using a version control system or copy = program that doesn't preserve timestamps), though that just pushes the = compatibility issue over to whatever lex/flex version the person = building the distribution has.... But, as long as they try it out = before putting it up for download, we should catch any problems fairly = easily. > I don=92t have any problem with Flex 2.5.35. Which version do you = use? Mac OS X includes flex 2.5.35, though I can't assert that Apple hasn't = tweaked it any. I tried this little test case: > % cat q.lex > %% > "hello" { return HELLO; } > %% > % flex q.lex > % grep yyget_leng lex.yy.c=20 > yy_size_t yyget_leng (void ); > yy_size_t yyget_leng (void) > %=20 And yy_size_t is defined to be size_t. Does it not insert such declarations for you on your system? >> - "$(srcdir)/$(snarf_doc).scm" > "$@.tmp" >> + "$(snarf_doc).scm" > "$@.tmp" >=20 > This one seems wrong to me since $(snarf_doc).scm is in $(srcdir), not > $(builddir). Yes, though changing load-module to interpret paths relative to the = working directory rather than the currently loading module looks wrong = too. >=20 > Instead I suggest changing $(srcdir) to $(abs_srcdir), which should > solve the problem. Thus sidestepping the whole question of how a non-absolute pathname = argument to make-texinfo.scm should be interpreted.... Perhaps it = should complain if you give a non-absolute name, if we're not going to = settle the question? > Can you confirm and commit? Sure -- done, and done. And with the right upstream branch name this = time. :-) But... a new issue -- with SCM_DEBUG=3D1, my build fails: GUILE_AUTO_COMPILE=3D0 \ ../meta/uninstalled-env \ guile-tools compile -Wunbound-variable -Warity-mismatch -o = "language/glil/decompile-assembly.go" = "../../module/language/glil/decompile-assembly.scm" Non-pair accessed with SCM_C[AD]R: `#' make[2]: *** [language/glil/decompile-assembly.go] Abort trap (core = dumped) (gdb) bt #0 0x00007fff81777fe6 in kill () #1 0x00000001000cfb5f in scm_error_pair_access (non_pair=3D0x10195e230) = at ../../libguile/pairs.c:64 #2 0x0000000100022275 in scm_i_dowinds (to=3D0x101e125e0, delta=3D1, = turn_func=3D0, data=3D0x0) at ../../libguile/dynwind.c:309 #3 0x0000000100022390 in scm_dowinds (to=3D, delta=3D) at ../../libguile/dynwind.c:228 #4 0x000000010001a79e in scm_c_abort (vm=3D0x1006f3040, = tag=3D0x101a239a0, n=3D5, argv=3D0x7fff5fbfd3a0, cookie=3D50450) at = ../../libguile/control.c:230 #5 0x00000001001128ce in vm_abort (vm=3D, n=3D, vm_cookie=3D) at ../../libguile/vm.c:229 #6 0x000000010011a857 in vm_debug_engine (vm=3D0x1006f3040, = program=3D0x101083520, argv=3D0x101001970, nargs=3D1) at = vm-i-system.c:1546 [....] I note that 0x13d & 0x7f is 61 or scm_tc7_prompt... Ken=