guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build problems


From: Ken Raeburn
Subject: Re: build problems
Date: Thu, 4 Mar 2010 03:25:09 -0500

On Mar 2, 2010, at 05:23, Ludovic Courtès wrote:
>>> We don't actually reference yyget_leng elsewhere explicitly; can we just 
>>> get rid of the declaration?
>> 
>> 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
> 
> Keep in mind that ‘c-tokenize.c’ is part of the distribution, so we
> shouldn’t 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’t 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 
> yy_size_t yyget_leng (void );
> yy_size_t yyget_leng  (void)
> % 

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" > "address@hidden"
>> +         "$(snarf_doc).scm" > "address@hidden"
> 
> 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.

> 
> 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=1, my build fails:

GUILE_AUTO_COMPILE=0                                    \
        ../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: `#<unknown-type (0x13d . 0x101a239a0) @ 
0x101a23960>'
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=0x10195e230) at 
../../libguile/pairs.c:64
#2  0x0000000100022275 in scm_i_dowinds (to=0x101e125e0, delta=1, turn_func=0, 
data=0x0) at ../../libguile/dynwind.c:309
#3  0x0000000100022390 in scm_dowinds (to=<value temporarily unavailable, due 
to optimizations>, delta=<value temporarily unavailable, due to optimizations>) 
at ../../libguile/dynwind.c:228
#4  0x000000010001a79e in scm_c_abort (vm=0x1006f3040, tag=0x101a239a0, n=5, 
argv=0x7fff5fbfd3a0, cookie=50450) at ../../libguile/control.c:230
#5  0x00000001001128ce in vm_abort (vm=<value temporarily unavailable, due to 
optimizations>, n=<value temporarily unavailable, due to optimizations>, 
vm_cookie=<value temporarily unavailable, due to optimizations>) at 
../../libguile/vm.c:229
#6  0x000000010011a857 in vm_debug_engine (vm=0x1006f3040, program=0x101083520, 
argv=0x101001970, nargs=1) at vm-i-system.c:1546
[....]

I note that 0x13d & 0x7f is 61 or scm_tc7_prompt...

Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]