statically linking in srfi modules

statically linking in srfi modules

[Richard Shann]

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_init_srfi_1")
fails.
If OTOH I put --enable-shared then the link fails lacking further shared
libraries libgmp libltdl libunistring libintl libiconv.

Can someone suggest how to proceed - there is no critical objection to
using shared libraries, but all those libraries are already built in mxe
as static libraries; is there a way to build guile with the srfi stuff
ready linked in?

Richard Shann

Re: statically linking in srfi modules

[Richard Shann]

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 +0000, Richard Shann wrote:
> 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_init_srfi_1")
> fails.
> If OTOH I put --enable-shared then the link fails lacking further shared
> libraries libgmp libltdl libunistring libintl libiconv.
> 
> Can someone suggest how to proceed - there is no critical objection to
> using shared libraries, but all those libraries are already built in mxe
> as static libraries; is there a way to build guile with the srfi stuff
> ready linked in?
> 
> Richard Shann
> 

Re: statically linking in srfi modules

[Andy Wingo]

On Fri 08 Feb 2013 10:25, Richard Shann <richard.shann@virgin.net> writes:

> On Fri, 2013-02-08 at 09:24 +0000, 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 call

  scm_c_register_extension ("libguile-srfi-srfi-1-v-3", "scm_init_srfi_1",
                             scm_init_srfi_1, NULL)

somewhere in your C code.

> Oh - sorry, I should have mentioned, we are still on guile 1.8 (perhaps
> for no good reason?), if that affects the answer.

Same answer.  Guile 2.0 is much faster if that matters to you :)

Andy
-- 
http://wingolog.org/

Re: statically linking in srfi modules

[Richard Shann]

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 heap of errors...

It looks like this module is the only one doing the dynamic loading
thing, judging by grepping for extension in the files, but is there a
way of knowing?

Thanks in advance,

Richard



On Fri, 2013-02-08 at 12:27 +0100, Andy Wingo wrote:
> On Fri 08 Feb 2013 10:25, Richard Shann <richard.shann@virgin.net> writes:
> 
> > On Fri, 2013-02-08 at 09:24 +0000, 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 call
> 
>   scm_c_register_extension ("libguile-srfi-srfi-1-v-3", "scm_init_srfi_1",
>                              scm_init_srfi_1, NULL)
> 
> somewhere in your C code.
> 
> > Oh - sorry, I should have mentioned, we are still on guile 1.8 (perhaps
> > for no good reason?), if that affects the answer.
> 
> Same answer.  Guile 2.0 is much faster if that matters to you :)
> 
> Andy

Re: statically linking in srfi modules

[Richard Shann]

On Fri, 2013-02-08 at 13:02 +0000, 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 with it
> declared but
> #include "guile/srfi/srfi-1.h"
> gives a heap of errors...

Oh, sorry, that was daft, I needed to include libguile before that
header. Now it won't link ... so we will need to find the right library
name to link to...

Richard


> 
> It looks like this module is the only one doing the dynamic loading
> thing, judging by grepping for extension in the files, but is there a
> way of knowing?
> 
> Thanks in advance,
> 
> Richard
> 
> 
> 
> On Fri, 2013-02-08 at 12:27 +0100, Andy Wingo wrote:
> > On Fri 08 Feb 2013 10:25, Richard Shann <richard.shann@virgin.net> writes:
> > 
> > > On Fri, 2013-02-08 at 09:24 +0000, 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 call
> > 
> >   scm_c_register_extension ("libguile-srfi-srfi-1-v-3", "scm_init_srfi_1",
> >                              scm_init_srfi_1, NULL)
> > 
> > somewhere in your C code.
> > 
> > > Oh - sorry, I should have mentioned, we are still on guile 1.8 (perhaps
> > > for no good reason?), if that affects the answer.
> > 
> > Same answer.  Guile 2.0 is much faster if that matters to you :)
> > 
> > Andy
> 

Re: statically linking in srfi modules

[Richard Shann]

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 the error
message when srfi-1 tries to dynamically load 

<libguile-srfi-srfi-1-v-3 The specified module could not be found.>

I found some documentation on this call at
http://mulliken.chem.hope.edu/cgi-bin/info2www.cgi?(guile)Extensions

and it indicated the first argument could be NULL, which would reduce
the danger of a typo in that string causing trouble, but alas with NULL
the same error message occurs. I have checked that scm_init_srfi_1 is a
genuinely non-null pointer, so I don't quite know where to go next. I
have gdb running on the windows box (again, thanks to the mxe
cross-compilation project), but perhaps someone can spare me tracking
through the libguile-srfi-srfi-1-v-3.a code?

Richard


On Fri, 2013-02-08 at 12:27 +0100, Andy Wingo wrote:
> On Fri 08 Feb 2013 10:25, Richard Shann <richard.shann@virgin.net>
> writes:
> 
> > On Fri, 2013-02-08 at 09:24 +0000, 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 call
> 
>   scm_c_register_extension ("libguile-srfi-srfi-1-v-3",
> "scm_init_srfi_1",
>                              scm_init_srfi_1, NULL)
> 
> somewhere in your C code.
> 
> 

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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), but disappointingly I still get the error
> message when srfi-1 tries to dynamically load 
>
> <libguile-srfi-srfi-1-v-3 The specified module could not be found.>

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,
so that Denemo users who wish to use the string or character set
libraries can do so.

      Mark

Re: statically linking in srfi modules

[Mark H Weaver]

I wrote:

> Richard Shann <richard.shann@virgin.net> writes:
>
>> <libguile-srfi-srfi-1-v-3 The specified module could not be found.>
>
> 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,
> so that Denemo users who wish to use the string or character set
> libraries can do so.

Sorry, I was mistaken.  It turns out that srfi-13-14 was moved into the
core a while ago, and that shared library is just an empty dummy
library.  The same is true of srfi-4.

However, there's also a shared library for srfi-60, which should be
statically linked as well.  Just as for srfi-1, the call to
'load-extension' should be removed from srfi-60.scm, and you should add
the following to your C initialization code:

  scm_c_register_extension ("libguile-srfi-srfi-60-v-2", "scm_init_srfi_60",
                             scm_init_srfi_60, NULL);

    Regards,
      Mark

Re: statically linking in srfi modules

[Richard Shann]

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 response.
Richard

On Fri, 2013-02-08 at 17:11 -0500, Mark H Weaver wrote:
> I wrote:
> 
> > Richard Shann <richard.shann@virgin.net> writes:
> >
> >> <libguile-srfi-srfi-1-v-3 The specified module could not be found.>
> >
> > 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,
> > so that Denemo users who wish to use the string or character set
> > libraries can do so.
> 
> Sorry, I was mistaken.  It turns out that srfi-13-14 was moved into the
> core a while ago, and that shared library is just an empty dummy
> library.  The same is true of srfi-4.
> 
> However, there's also a shared library for srfi-60, which should be
> statically linked as well.  Just as for srfi-1, the call to
> 'load-extension' should be removed from srfi-60.scm, and you should add
> the following to your C initialization code:
> 
>   scm_c_register_extension ("libguile-srfi-srfi-60-v-2", "scm_init_srfi_60",
>                              scm_init_srfi_60, NULL);
> 
>     Regards,
>       Mark

Re: statically linking in srfi modules

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> 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 to use it (see
<http://thread.gmane.org/gmane.lisp.guile.devel/7897>).

Ludo’.

Re: statically linking in srfi modules

[Richard Shann]

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 feed it any
scheme expression and have it evaluated to debug the problem...

Richard




On Fri, 2013-02-08 at 17:11 -0500, Mark H Weaver wrote:
> I wrote:
> 
> > Richard Shann <richard.shann@virgin.net> writes:
> >
> >> <libguile-srfi-srfi-1-v-3 The specified module could not be found.>
> >
> > 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,
> > so that Denemo users who wish to use the string or character set
> > libraries can do so.
> 
> Sorry, I was mistaken.  It turns out that srfi-13-14 was moved into the
> core a while ago, and that shared library is just an empty dummy
> library.  The same is true of srfi-4.
> 
> However, there's also a shared library for srfi-60, which should be
> statically linked as well.  Just as for srfi-1, the call to
> 'load-extension' should be removed from srfi-60.scm, and you should add
> the following to your C initialization code:
> 
>   scm_c_register_extension ("libguile-srfi-srfi-60-v-2", "scm_init_srfi_60",
>                              scm_init_srfi_60, NULL);
> 
>     Regards,
>       Mark

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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 try replacing the calls to
'scm_c_register_extension' with the following:

  scm_c_define_module ("srfi srfi-1",  init_srfi_1,  NULL);
  scm_c_define_module ("srfi srfi-60", init_srfi_60, NULL);

Where 'init_srfi_1' and 'init_srfi_60' are defined as follows:

  static void init_srfi_1  (void *dummy) { scm_init_srfi_1  (); }
  static void init_srfi_60 (void *dummy) { scm_init_srfi_60 (); }

     Mark

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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 wrong.  Please try replacing the calls to
> 'scm_c_register_extension' with the following:
>
>   scm_c_define_module ("srfi srfi-1",  init_srfi_1,  NULL);
>   scm_c_define_module ("srfi srfi-60", init_srfi_60, NULL);
[...]

Sorry, this isn't quite right either.  Instead of the above, please try
replacing the calls to 'scm_c_register_extension' with the following:

  scm_c_call_with_current_module (scm_c_resolve_module ("srfi srfi-1"),
                                  init_srfi_1, NULL);
  scm_c_call_with_current_module (scm_c_resolve_module ("srfi srfi-60"),
                                  init_srfi_60, NULL);

Where 'init_srfi_1' and 'init_srfi_60' are defined as follows:

  static SCM
  init_srfi_1 (void *dummy)
  {
    scm_init_srfi_1 ();
    return SCM_UNSPECIFIED;
  }

  static SCM
  init_srfi_60 (void *dummy)
  {
    scm_init_srfi_60 ();
    return SCM_UNSPECIFIED;
  }

Hopefully this will work.  I'm too lazy to try it myself.

      Mark

Re: statically linking in srfi modules

[Richard Shann]

On Sat, 2013-02-09 at 10:32 -0500, Mark H Weaver wrote:
> Richard Shann <richard.shann@virgin.net> 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 wrong.  Please try replacing the calls to
> > 'scm_c_register_extension' with the following:
> >
> >   scm_c_define_module ("srfi srfi-1",  init_srfi_1,  NULL);
> >   scm_c_define_module ("srfi srfi-60", init_srfi_60, NULL);
> [...]

This worked in that map was defined, but then make-regexp was undefined
- we (use-modules (ice-9 regex)) in our opening preamble, which I guess
may re-define that, but grepping through the ice-9 directory I didn't
see any sign of the load-extension call that happens in srfi-1 and 60.
> 
> Sorry, this isn't quite right either.  Instead of the above, please try
> replacing the calls to 'scm_c_register_extension' with the following:
> 
>   scm_c_call_with_current_module (scm_c_resolve_module ("srfi srfi-1"),
>                                   init_srfi_1, NULL);
>   scm_c_call_with_current_module (scm_c_resolve_module ("srfi srfi-60"),
>                                   init_srfi_60, NULL);
> 
> Where 'init_srfi_1' and 'init_srfi_60' are defined as follows:
> 
>   static SCM
>   init_srfi_1 (void *dummy)
>   {
>     scm_init_srfi_1 ();
>     return SCM_UNSPECIFIED;
>   }
> 
>   static SCM
>   init_srfi_60 (void *dummy)
>   {
>     scm_init_srfi_60 ();
>     return SCM_UNSPECIFIED;
>   }
> 
This seemed to have a dramatic effect! The program exits at startup with
the message
ERROR: Unbound variable: map

and return status 1

Until now I felt we were converging on something :) One thing that
puzzles me is that other srfi numbers have static libraries generated
for them, but on 1 and 60 would seem to be needed?
Thanks for the support...

Richard

Re: statically linking in srfi modules

[Richard Shann]

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

Re: statically linking in srfi modules

[Mark H Weaver]

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 additional definitions:

  static SCM
  init_srfi_1 (void)
  {
    scm_init_srfi_1 ();
    return SCM_UNSPECIFIED;
  }

  static SCM
  init_srfi_60 (void)
  {
    scm_init_srfi_60 ();
    return SCM_UNSPECIFIED;
  }

  static SCM
  bind_srfi_initializers (void *dummy)
  {
    scm_c_define_gsubr ("%init-srfi-1",  0, 0, 0, init_srfi_1);
    scm_c_define_gsubr ("%init-srfi-60", 0, 0, 0, init_srfi_60);
    return SCM_UNSPECIFIED;
  }

Then, starting with the original versions of srfi-1.scm and srfi-60.scm
from Guile 1.8, replace the (load-extension ...) calls in those two
files with (%init-srfi-1) and (%init-srfi-60), respectively.

   *crosses fingers*
         Mark

Re: statically linking in srfi modules

[Richard Shann]

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"),
>                                   bind_srfi_initializers, NULL);
> 
> With the following additional definitions:
> 
>   static SCM
>   init_srfi_1 (void)
>   {
>     scm_init_srfi_1 ();
>     return SCM_UNSPECIFIED;
>   }
> 
>   static SCM
>   init_srfi_60 (void)
>   {
>     scm_init_srfi_60 ();
>     return SCM_UNSPECIFIED;
>   }
> 
>   static SCM
>   bind_srfi_initializers (void *dummy)
>   {
>     scm_c_define_gsubr ("%init-srfi-1",  0, 0, 0, init_srfi_1);
>     scm_c_define_gsubr ("%init-srfi-60", 0, 0, 0, init_srfi_60);
>     return SCM_UNSPECIFIED;
>   }
> 
> Then, starting with the original versions of srfi-1.scm and srfi-60.scm
> from Guile 1.8, replace the (load-extension ...) calls in those two
> files with (%init-srfi-1) and (%init-srfi-60), respectively.
With this Denemo starts up looking very good - no error messages from
any of the scheme executed on startup. However the symbol make-regexp is
undefined. Denemo executes 

(use-modules (srfi srfi-1)) ; List library
(use-modules (srfi srfi-8)) ; Returning and Accepting Multiple Values
(use-modules (srfi srfi-13)) ; String library
(use-modules (ice-9 regex)) ; regular expressions
(use-modules (ice-9 optargs)) ; optional (define* ) arguments
(use-modules (ice-9 q)) ; queue module

at startup.
I have displayed (defined? 'make-regexp) and it is #f from before the
first of those module loads and remains #f throughout.
 
I am not sure if it is defined or merely re-defined by (ice-9 regex).

Could this be a side effect of those initialization calls made in the C
code? Or is this a separate problem? ... I realize that I don't know for
sure that srfi-1 has successfully loaded - is there a simple test for
that?

Thanks for your patience,

Richard

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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 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-regexp' will not be available.  Search for 'regex' and 'rxposix'
in 'config.log' for details on what went wrong.

    Regards,
      Mark

Re: statically linking in srfi modules

[Richard Shann]

On Sun, 2013-02-10 at 10:35 -0500, Mark H Weaver wrote:
> Richard Shann <richard.shann@virgin.net> 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 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-regexp' will not be available.  Search for 'regex' and 'rxposix'
> in 'config.log' for details on what went wrong.
Thanks for the insight - I have asked on the mxe mailing list, as I
guess this is a problem of their make file. But in case you can help
here too, I deliberately triggered a failed build so that I could get at
the config.log file and I found this within:

...
configure:25048: checking for regex.h
configure:25057: result: yes
configure:24937: checking rxposix.h usability
configure:24954: i686-pc-mingw32-gcc -c -Wno-unused-but-set-variable
conftest.c >&5
conftest.c:96:21: fatal error: rxposix.h: No such file or directory
...

the resultant config.h has

/* Define to 1 if you have the `regex' library (-lregex). */
/* #undef HAVE_LIBREGEX */

which I guess means it is undefined...

I can't seem to track down anything about rxposix.h though ...

Richard

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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-regexp' will not be available.  Search for 'regex' and 'rxposix'
>> in 'config.log' for details on what went wrong.
> Thanks for the insight - I have asked on the mxe mailing list, as I
> guess this is a problem of their make file. But in case you can help
> here too, I deliberately triggered a failed build so that I could get at
> the config.log file and I found this within:
>
> ...
> configure:25048: checking for regex.h
> configure:25057: result: yes
> configure:24937: checking rxposix.h usability
> configure:24954: i686-pc-mingw32-gcc -c -Wno-unused-but-set-variable
> conftest.c >&5
> conftest.c:96:21: fatal error: rxposix.h: No such file or directory
> ...
>
> the resultant config.h has
>
> /* Define to 1 if you have the `regex' library (-lregex). */
> /* #undef HAVE_LIBREGEX */
>
> which I guess means it is undefined...
>
> I can't seem to track down anything about rxposix.h though ...

Don't worry about rxposix.h.  We need only one of regex.h, rxposix.h, or
rx/rxposix.h, and it doesn't matter which one.

The problem now is that ./configure was apparently unable to find out
how to link in the 'regcomp' function.  Search for 'regcomp' in
'configure.in' to see the source code for the relevant tests.  Search
for 'regcomp', 'regex', and 'rx' in 'config.log' to see more detail
about what went wrong.  Note that 'GUILE_NAMED_CHECK_FUNC' is defined in
'acinclude.m4'.

    Regards,
      Mark

Re: statically linking in srfi modules

[Richard Shann]

On Sun, 2013-02-10 at 21:02 -0500, Mark H Weaver wrote:
> Richard Shann <richard.shann@virgin.net> 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-regexp' will not be available.  Search for 'regex' and 'rxposix'
> >> in 'config.log' for details on what went wrong.
> > Thanks for the insight - I have asked on the mxe mailing list, as I
> > guess this is a problem of their make file. But in case you can help
> > here too, I deliberately triggered a failed build so that I could get at
> > the config.log file and I found this within:
> >
> > ...
> > configure:25048: checking for regex.h
> > configure:25057: result: yes
> > configure:24937: checking rxposix.h usability
> > configure:24954: i686-pc-mingw32-gcc -c -Wno-unused-but-set-variable
> > conftest.c >&5
> > conftest.c:96:21: fatal error: rxposix.h: No such file or directory
> > ...
> >
> > the resultant config.h has
> >
> > /* Define to 1 if you have the `regex' library (-lregex). */
> > /* #undef HAVE_LIBREGEX */
> >
> > which I guess means it is undefined...
> >
> > I can't seem to track down anything about rxposix.h though ...
> 
> Don't worry about rxposix.h.  We need only one of regex.h, rxposix.h, or
> rx/rxposix.h, and it doesn't matter which one.
> 
> The problem now is that ./configure was apparently unable to find out
> how to link in the 'regcomp' function.  Search for 'regcomp' in
> 'configure.in' to see the source code for the relevant tests.

configure:31896: i686-pc-mingw32-gcc -o conftest.exe
-Wno-unused-but-set-variable
-I/home/rshann/mxe/usr/i686-pc-mingw32/include  conftest.c -lgmp
-lws2_32 -lm -lltdl -lunistring -lintl -liconv >&5
/tmp/cc8nE0P9.o:conftest.c:(.text+0xc): undefined reference to `regcomp'

configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "guile"
| #define PACKAGE_TARNAME "guile"
| #define PACKAGE_VERSION "1.8.7"
| #define PACKAGE_STRING "guile 1.8.7"
| #define PACKAGE_BUGREPORT "bug-guile@gnu.org"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_LIBLTDL 1
| #define SCM_WARN_DEPRECATED_DEFAULT "summary"
| #define GUILE_USE_64_CALLS 1
| #define HAVE_POSIX 1
| #define HAVE_NETWORKING 1
| #define SIZEOF_CHAR 1
| #define SIZEOF_UNSIGNED_CHAR 1
| #define SIZEOF_SHORT 2
| #define SIZEOF_UNSIGNED_SHORT 2
| #define SIZEOF_INT 4
| #define SIZEOF_UNSIGNED_INT 4
| #define SIZEOF_LONG 4
| #define SIZEOF_UNSIGNED_LONG 4
| #define SIZEOF_SIZE_T 4
| #define SIZEOF_LONG_LONG 8
| #define SIZEOF_UNSIGNED_LONG_LONG 8
| #define SIZEOF___INT64 8
| #define SIZEOF_UNSIGNED___INT64 8
| #define SIZEOF_VOID_P 4
| #define SIZEOF_INTPTR_T 4
| #define SIZEOF_UINTPTR_T 4
| #define SIZEOF_PTRDIFF_T 4
| #define SIZEOF_SIZE_T 4
| #define SIZEOF_OFF_T 4
| #define HAVE_STDINT_H 1
| #define HAVE_INTTYPES_H 1
| #define SIZEOF_INTMAX_T 8
| #define STDC_HEADERS 1
| #define TIME_WITH_SYS_TIME 1
| #define HAVE_DIRENT_H 1
| #define HAVE_COMPLEX_H 1
| #define HAVE_FENV_H 1
| #define HAVE_IO_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_MALLOC_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_PROCESS_H 1
| #define HAVE_STRING_H 1
| #define HAVE_REGEX_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_TIMEB_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_UTIME_H 1
| #define HAVE_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_DIRECT_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_COMPLEX_DOUBLE 1
| #define socklen_t int
| #define HAVE_UNISTD_H 1
| #define uid_t int
| #define gid_t int
| #define GETGROUPS_T int
| #define RETSIGTYPE void
| #define HAVE_LIBM 1
| #define HAVE_WINSOCK2_H 1
| #define HAVE_LIBWS2_32 1
| #define HAVE_ASSERT_H 1
| #define HAVE_CEXP 1
| #define HAVE_CHSIZE 1
| #define HAVE_CLOG 1
| #define HAVE_FESETROUND 1
| #define HAVE_FTIME 1
| #define HAVE_FTRUNCATE 1
| #define HAVE_GETCWD 1
| #define HAVE_GETTIMEOFDAY 1
| #define HAVE_MKDIR 1
| #define HAVE__PIPE 1
| #define HAVE_RENAME 1
| #define HAVE_RMDIR 1
| #define HAVE_SETLOCALE 1
| #define HAVE_STRFTIME 1
| #define HAVE_STRDUP 1
| #define HAVE_SYSTEM 1
| #define HAVE_USLEEP 1
| #define HAVE_ATEXIT 1
| #define HAVE_STRCHR 1
| #define HAVE_STRCMP 1
| #define HAVE_MEMCPY 1
| #define HAVE_ISBLANK 1
| #define HAVE_STRNCASECMP 1
| #define HAVE_PTHREAD_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_DECL_SETHOSTNAME 0
| #define HAVE_DECL_STRNCASECMP 1
| #define HAVE_DECL_UNSETENV 0
| #define HAVE_DECL_HSTRERROR 0
| #define HAVE_DECL_CUSERID 0
| #define HAVE_DECL_FLOCK 0
| #define HAVE_DECL_VSNPRINTF 1
| #define GUILE_I _Complex_I
| #define HAVE_USABLE_CSQRT 1
| #define HAVE_LIBGMP 1
| #define HAVE_ICONV 1
| #define ENABLE_NLS 1
| #define HAVE_GETTEXT 1
| #define HAVE_DCGETTEXT 1
| #define HAVE_DECL_STRPTIME 0
| #define HAVE_TZSET 1
| #define LOCALTIME_CACHE 1
| /* end confdefs.h.  */
| /* System header to define __stub macros and hopefully few prototypes,
|     which can conflict with char regcomp(); below.  */
| #include <assert.h>
| /* Override any gcc2 internal prototype to avoid an error.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| /* We use char because int might match the return type of a gcc2
|     builtin and then its argument prototype would still apply.  */
| char regcomp();
| 
| int
| main ()
| {
| 
| /* The GNU C library defines this for functions which it implements
|     to always fail with ENOSYS.  Some functions are actually named
|     something starting with __ and the normal name is an alias.  */
| #if defined (__stub_regcomp) || defined (__stub___regcomp)
| choke me
| #else
| regcomp();
| #endif
| 
|   ;
|   return 0;
| }


I am a bit out of my depth here ... these seem to be the libraries that
could plausibly provide regcomp(), )
(by running find . -name '*regex*' -print)

./usr/i686-pc-mingw32/lib/libboost_regex-mt.a
./usr/i686-pc-mingw32/lib/libwxregexu-2.8-i686-pc-mingw32.a
./usr/i686-pc-mingw32/lib/libwxregex-2.8-i686-pc-mingw32.a
./usr/i686-pc-mingw32/lib/libboost_regex-mt-d.a

none of these appear on the link line for the regcomp test - I can't see
where it gets that set of libraries to link to...

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 -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/mxe/usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lregex
collect2: error: ld returned 1 exit status

That must surely be a clue, and perhaps a bug, I presume the default is
to have regex built?

Any further help will be much appreciated...

Richard

>   Search
> for 'regcomp', 'regex', and 'rx' in 'config.log' to see more detail
> about what went wrong.  Note that 'GUILE_NAMED_CHECK_FUNC' is defined in
> 'acinclude.m4'.
> 
>     Regards,
>       Mark

Re: statically linking in srfi modules

[Richard Shann]

On Mon, 2013-02-11 at 10:05 +0000, 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 -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/mxe/usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lregex
> collect2: error: ld returned 1 exit status
> 
> That must surely be a clue, and perhaps a bug, I presume the default
> is
> to have regex built? 
Sorry - 
I think I was getting fooled here by repeated sections of stuff,
checking for regcomp occurs three times and there is this:

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/mxe/usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lregex

probably in all cases.

Richard

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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/mxe/usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lregex
>
> probably in all cases.

Can you find out where the 'regcomp' function is?  If you can find it,
you could pass LDFLAGS=-lfoobar to ./configure.  My suspicion is that
it's missing from your MXE build.  Another possibility is that 'regcomp'
is a preprocessor macro in one of the include files, which the current
tests would fail to detect.

> I am a bit out of my depth here ... these seem to be the libraries that
> could plausibly provide regcomp(), )
> (by running find . -name '*regex*' -print)
> 
> ./usr/i686-pc-mingw32/lib/libboost_regex-mt.a
> ./usr/i686-pc-mingw32/lib/libwxregexu-2.8-i686-pc-mingw32.a
> ./usr/i686-pc-mingw32/lib/libwxregex-2.8-i686-pc-mingw32.a
> ./usr/i686-pc-mingw32/lib/libboost_regex-mt-d.a

These aren't the droids you're looking for.  Guile 1.8's ./configure
seems to be looking for either libregex or librx, though I confess that
my autoconf skills are weak.

      Mark

Re: statically linking in srfi modules

[Richard Shann]

On Mon, 2013-02-11 at 12:03 -0500, Mark H Weaver wrote:
> Richard Shann <richard.shann@virgin.net> 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/mxe/usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lregex
> >
> > probably in all cases.
> 
> 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 as a separate library. 
http://lilypond.org/download/gub-sources/regex-2.3.90-1.tar.bz2

By building this with --disable-shared I have obtained a library which
links to guile and ice-9/regex is now working inside Denemo.

Thank you very much for your help. I don't know if there is anything
that it would be good to do upstream as a result of this epic little
voyage ...

Richard

>  If you can find it,
> you could pass LDFLAGS=-lfoobar to ./configure.  My suspicion is that
> it's missing from your MXE build.  Another possibility is that 'regcomp'
> is a preprocessor macro in one of the include files, which the current
> tests would fail to detect.
> 
> > I am a bit out of my depth here ... these seem to be the libraries that
> > could plausibly provide regcomp(), )
> > (by running find . -name '*regex*' -print)
> > 
> > ./usr/i686-pc-mingw32/lib/libboost_regex-mt.a
> > ./usr/i686-pc-mingw32/lib/libwxregexu-2.8-i686-pc-mingw32.a
> > ./usr/i686-pc-mingw32/lib/libwxregex-2.8-i686-pc-mingw32.a
> > ./usr/i686-pc-mingw32/lib/libboost_regex-mt-d.a
> 
> These aren't the droids you're looking for.  Guile 1.8's ./configure
> seems to be looking for either libregex or librx, though I confess that
> my autoconf skills are weak.
> 
>       Mark

Re: statically linking in srfi modules

[Mark H Weaver]

Richard Shann <richard.shann@virgin.net> 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 as a separate library. 
> http://lilypond.org/download/gub-sources/regex-2.3.90-1.tar.bz2
>
> By building this with --disable-shared I have obtained a library which
> links to guile and ice-9/regex is now working inside Denemo.

Excellent!

> Thank you very much for your help. I don't know if there is anything
> that it would be good to do upstream as a result of this epic little
> voyage ...

Glad to help, and thanks for letting us know how it went.

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
dynamically-loaded extension bundled with Guile 2 is for readline.
It would be good to fix that at some point.

    Regards,
      Mark

Re: statically linking in srfi modules

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> 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
> dynamically-loaded extension bundled with Guile 2 is for readline.
> It would be good to fix that at some point.

I don’t think it should be “fixed” because (1) it’s an optional feature,
and (2) it’s under the GPL whereas Guile is under LGPL.

Ludo’.