Mark H Weaver skribis:
> I guess the main thing for us to do upstream is to ensure that
> --disable-shared works properly without such workarounds. Fortunately
> this is mostly not an issue in Guile 2, because the SRFI-1 and SRFI-60
> libraries have been moved into the core. The only remaining
Richard Shann writes:
> On Mon, 2013-02-11 at 12:03 -0500, Mark H Weaver wrote:
>>
>> Can you find out where the 'regcomp' function is?
> Well, I tracked back from the GNU/LilyPond build system - it seems to
> originate in glibc, but in the GNU/LilyPond build system it has been
> extracted out
On Mon, 2013-02-11 at 12:03 -0500, Mark H Weaver wrote:
> Richard Shann writes:
> > configure:31783: checking for main in -lregex
> > configure:31812: i686-pc-mingw32-gcc -o conftest.exe
> > -Wno-unused-but-set-variable
> > -I/home/rshann/mxe/usr/i686-pc-mingw32/include conftest.c -lregex
> > -lg
Richard Shann writes:
> configure:31783: checking for main in -lregex
> configure:31812: i686-pc-mingw32-gcc -o conftest.exe
> -Wno-unused-but-set-variable
> -I/home/rshann/mxe/usr/i686-pc-mingw32/include conftest.c -lregex
> -lgmp -lws2_32 -lm -lltdl -lunistring -lintl -liconv >&5
> /home/rshann
On Mon, 2013-02-11 at 10:05 +, Richard Shann wrote:
> I noticed that the invocation of the guile build was accepting the
> default for regex, so I tried setting it explicitly
> with --enable-regex=yes in the configure. With this I see in
> config.log
>
> configure:31783: checking for main in -
On Sun, 2013-02-10 at 21:02 -0500, Mark H Weaver wrote:
> Richard Shann writes:
> > On Sun, 2013-02-10 at 10:35 -0500, Mark H Weaver wrote:
> >> This is an unrelated problem, namely that './configure' is apparently
> >> unable to find a suitable POSIX regexp library. I think you'll find
> >> that
Richard Shann writes:
> On Sun, 2013-02-10 at 10:35 -0500, Mark H Weaver wrote:
>> This is an unrelated problem, namely that './configure' is apparently
>> unable to find a suitable POSIX regexp library. I think you'll find
>> that HAVE_REGCOMP is not defined in 'config.h', in which case
>> 'make
On Sun, 2013-02-10 at 10:35 -0500, Mark H Weaver wrote:
> Richard Shann writes:
> > With this Denemo starts up looking very good - no error messages from
> > any of the scheme executed on startup.
>
> Good. I think the SRFI problem is finally solved.
>
> > However the symbol make-regexp is unde
Richard Shann writes:
> With this Denemo starts up looking very good - no error messages from
> any of the scheme executed on startup.
Good. I think the SRFI problem is finally solved.
> However the symbol make-regexp is undefined.
This is an unrelated problem, namely that './configure' is app
On Sat, 2013-02-09 at 21:00 -0500, Mark H Weaver wrote:
> Hi Richard,
>
> Don't worry, we'll get it working. Here's another attempt.
> Replace the calls to 'scm_c_register_extension' with the following:
>
> scm_c_call_with_current_module (scm_c_resolve_module ("guile"),
>
Hi Richard,
Don't worry, we'll get it working. Here's another attempt.
Replace the calls to 'scm_c_register_extension' with the following:
scm_c_call_with_current_module (scm_c_resolve_module ("guile"),
bind_srfi_initializers, NULL);
With the following additi
More on that call to
scm_c_call_with_current_module (scm_c_resolve_module ("srfi srfi-1"),
init_srfi_1, NULL);
I have had a look using gdb and it is exiting during the call to
scm_c_resolve_module()
HTH
Richard
On Sat, 2013-02-09 at 10:32 -0500, Mark H Weaver wrote:
> Richard Shann writes:
> > Well it seems I may have been premature in saying that srfi-1 was
> > successfully loaded. Although the error message is gone, there is no
> > symbol 'map which srfi-1 should have re-defined.
> > Can someone sugge
Richard Shann writes:
> Well it seems I may have been premature in saying that srfi-1 was
> successfully loaded. Although the error message is gone, there is no
> symbol 'map which srfi-1 should have re-defined.
> Can someone suggest what this might be a symptom of?
I wrote:
> I know what's wro
Richard Shann writes:
> Well it seems I may have been premature in saying that srfi-1 was
> successfully loaded. Although the error message is gone, there is no
> symbol 'map which srfi-1 should have re-defined.
> Can someone suggest what this might be a symptom of?
I know what's wrong. Please
Well it seems I may have been premature in saying that srfi-1 was
successfully loaded. Although the error message is gone, there is no
symbol 'map which srfi-1 should have re-defined.
Can someone suggest what this might be a symptom of?
Denemo has a command line interpreter for guile, so I can fe
Mark H Weaver skribis:
> The problem is the call to 'load-extension' near the top of
> 'srfi-1.scm', which again tries to load that shared library.
> You'll have to remove that call from 'srfi-1.scm'.
Actually ltdl supports “preloaded libraries”, but that would mean
reworking 1.8’s build system
Thank you very much - that does indeed fix the module loading problem.
As always, there is one last glitch. It seems that internationalization
is missing - no _ symbol for translating strings.
But I'll leave that until tomorrow to investigate - I just wanted to
thank you all very much for the rapid
I wrote:
> Richard Shann writes:
>
>>
>
> The problem is the call to 'load-extension' near the top of
> 'srfi-1.scm', which again tries to load that shared library.
> You'll have to remove that call from 'srfi-1.scm'.
>
> You should probably do the same thing for libguile-srfi-srfi-13-14-v-3,
>
Richard Shann writes:
> I succeeded in linking Denemo with the call
>
> scm_c_register_extension ("libguile-srfi-srfi-1-v-3", "scm_init_srfi_1",
> scm_init_srfi_1, NULL);
> inserted right at the beginning of inner_main (the value passed to
> scm_boot_guile, that is)
I succeeded in linking Denemo with the call
scm_c_register_extension ("libguile-srfi-srfi-1-v-3", "scm_init_srfi_1",
scm_init_srfi_1, NULL);
inserted right at the beginning of inner_main (the value passed to
scm_boot_guile, that is), but disappointingly I still get t
On Fri, 2013-02-08 at 13:02 +, Richard Shann wrote:
> Hmm, I can't find scm_c_register_extension in the guile reference index,
> and though including libguile.h finds the function I get the error
> message scm_init_srfi_1 undeclared...
> Hunting around for this symbol I see the header srfi-1.h
Hmm, I can't find scm_c_register_extension in the guile reference index,
and though including libguile.h finds the function I get the error
message scm_init_srfi_1 undeclared...
Hunting around for this symbol I see the header srfi-1.h with it
declared but
#include "guile/srfi/srfi-1.h"
gives a hea
On Fri 08 Feb 2013 10:25, Richard Shann writes:
> On Fri, 2013-02-08 at 09:24 +, Richard Shann wrote:
>> Is it possible to statically link in the srfi modules?
>> (load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1")
>> fails.
You can link it in I think, but then you will need to cal
Oh - sorry, I should have mentioned, we are still on guile 1.8 (perhaps
for no good reason?), if that affects the answer.
Richard
On Fri, 2013-02-08 at 09:24 +, Richard Shann wrote:
> Is it possible to statically link in the srfi modules? For GNU/Denemo we
> are currently trying http://mxe.cc
Is it possible to statically link in the srfi modules? For GNU/Denemo we
are currently trying http://mxe.cc to build for ms windows. Guile is
being built with --disable-shared and in consequence when denemo loads
srfi-1 the dynamic loading it does:
(load-extension "libguile-srfi-srfi-1-v-3" "scm_in
26 matches
Mail list logo
