headers
Ryan VanderBijl | 1 Jun 2006 17:37

compile problems

FYI: I had the following problems compiling guile 1.8.0 under cygwin:

1. configure couldn't find ltdl library, nor header file.
2. read.c:332 s_vector declared but not used warning,
when configured with --disable-elisp. 
Easily fixed by some ifdefs.
3. throw.c:495 scm_handle_by_message control reaches end 
of non-void function.
Not sure what the correct behavior should be, perhaps
it should 'return SCM_BOOL_F;' like the function
scm_handle_by_message_noexit?

gcc (GCC) 3.4.4 (cygming special)

-Ryan

--

-- 
Ryan VanderBijl   |   http://vbijl.net/~ryan/

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 1 comment |
headers
Kevin Ryde | 3 Jun 2006 01:35
Picon
Picon

Re: compile problems

Ryan VanderBijl <ryan <at> vbijl.net> writes:
>
> 1. configure couldn't find ltdl library, nor header file.

You need to install libtool (or the ltdl part of it).  Guile no longer
comes with an out-of-date version :).

> 2. read.c:332 s_vector declared but not used warning,
> when configured with --disable-elisp. 

Thanks.

> Easily fixed by some ifdefs.

Or not forcing -Werror on unsuspecting users :-(.

> 3. throw.c:495 scm_handle_by_message control reaches end 
> of non-void function.

Thanks.

> Not sure what the correct behavior should be, perhaps
> it should 'return SCM_BOOL_F;' like the function
> scm_handle_by_message_noexit?

It doesn't return so it doesn't matter.  I guess exit or pthread_exit
isn't marked as noreturn.

_______________________________________________
Bug-guile mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Ryde | 3 Jun 2006 01:24
Picon
Picon

Re: parallel make fails for guile 1.8

Neil Jerram <neil <at> ossau.uklinux.net> writes:
>
> I would guess this means that the Makefile
> is failing to work out that the libguile .c files depend on
> scmconfig.h,

Yep.  I added scmconfig.h to the .x and .doc files dependencies,
because they run cpp.

For the .o files depending on scmconfig.h, I don't think there's a
good way to express that with automake.  The magic dependency tracking
might be supposed to do it, but I find that too painful.

BUILT_SOURCES (where scmconfig.h already is) is usually the easiest
way to get stuff done before building main .o files etc.  In our case
its defeated because guile.texi is in BUILT_SOURCES too, and it
depends on the main "guile" target, so that starts on the .o files for
libguile (under a parallel make).  But is guile.texi actually used for
anything?

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 3 comments |
headers
Neil Jerram | 4 Jun 2006 10:45

Re: parallel make fails for guile 1.8

Kevin Ryde <user42 <at> zip.com.au> writes:

> Neil Jerram <neil <at> ossau.uklinux.net> writes:
>>
>> I would guess this means that the Makefile
>> is failing to work out that the libguile .c files depend on
>> scmconfig.h,
>
> Yep.  I added scmconfig.h to the .x and .doc files dependencies,
> because they run cpp.
>
> For the .o files depending on scmconfig.h, I don't think there's a
> good way to express that with automake.  The magic dependency tracking
> might be supposed to do it, but I find that too painful.
>
> BUILT_SOURCES (where scmconfig.h already is) is usually the easiest
> way to get stuff done before building main .o files etc.  In our case
> its defeated because guile.texi is in BUILT_SOURCES too, and it
> depends on the main "guile" target, so that starts on the .o files for
> libguile (under a parallel make).  But is guile.texi actually used for
> anything?

It's only used as part of the doc/maint/docstring.el mechanism for
keeping the manual in sync with libguile docstrings - see
doc/maint/README.

I think that means it can be certainly be removed from BUILT_SOURCES.
It probably doesn't need to be built automatically at all; a developer
can do "make guile.texi" when they need it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Ryde | 6 Jun 2006 02:46
Picon
Picon

Re: parallel make fails for guile 1.8

Neil Jerram <neil <at> ossau.uklinux.net> writes:
>
> I think that means it can be certainly be removed from BUILT_SOURCES.

Beaut, I did that.

> It probably doesn't need to be built automatically at all; a developer
> can do "make guile.texi" when they need it.

Sticking it in "nodist_noinst_DATA = guile.texi" seems to work to get
it built under "make all", if you still want it.  If normal users
don't need it then maybe it should be restricted to "if
ENABLE_MAINTAINER_MODE" though.

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 1 comment |
headers
Neil Jerram | 6 Jun 2006 22:08

Re: parallel make fails for guile 1.8

Kevin Ryde <user42 <at> zip.com.au> writes:

> Sticking it in "nodist_noinst_DATA = guile.texi" seems to work to get
> it built under "make all", if you still want it.  If normal users
> don't need it then maybe it should be restricted to "if
> ENABLE_MAINTAINER_MODE" though.

Thanks for noting that.  Feel free to go ahead with this if you like;
otherwise I think I'll wait until next time I actually need this,
before doing anything.

     Neil 

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 0 comments |
headers
Neil Jerram | 14 Jun 2006 02:45

Re: Bug in make-shared-array.

Marius Vollmer <mvo <at> zagadka.de> writes:

> Neil Jerram <neil <at> ossau.uklinux.net> writes:
>
>> in lines
>> 872-893, this -
>> 
>> 	  if (s[k].inc > 0)
>> 	    old_max += (s[k].ubnd - s[k].lbnd) * s[k].inc;
>> 	  else
>> 	    old_min += (s[k].ubnd - s[k].lbnd) * s[k].inc;
>> 
>> - suggests that (old_min, old_max) will be (inclusive, exclusive),
>
> Hmm, no, this loop computes the range of valid indices into the
> underlying storage vector and is not concerned with the number of
> elements.  Thus, all valid indices i must satisfy old_min <= i <=
> old_max.

Thanks for explaining this.  (And sorry for this late reply.)

> I'm inclined not to do anything about this until starting a bigger,
> more general cleanup of the code.  Thoughts?

Agreed.

Regards,
     Neil

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |

Gmane