Re: guile-2.0.0 fails to build without threads

[Andy Wingo]

On Mon 02 May 2011 08:20, Marco Maggi  writes:

> Andy Wingo wrote:
>>> stack size  (kbytes, -s) 8192
>>
>> This  should be  quite  large enough.   If  you are  still
>> interested  in   debugging  this  issue,   can  you  "call
>> scm_stack_report ()" in gdb from the scm_ithrow?
>
> Breakpoint 1, 0xb7f4fa80 in scm_ithrow ()
>from 
> /home/marco/src/devel/scheme/checkouts/guile/libguile/.libs/libguile-2.0.so.22
> (gdb) call scm_stack_report()
> fd7c of stack: 0xbfffe268 - 0xbfffe008

Thanks.  You seem to be running on system in which the stack grows up.
Is that the case?  Check libguile/scmconfig.h and config.log.

You mention in your original report:

  In the stable-2.0 branch I do:

$ git clean -dxf
$ ./autogen.sh
$ ./configure \
--prefix=3D/usr/local \
--enable-shared --disable-static \
CFLAGS=3D'-O3 -march=3Di686 -mtune=3Di686'

Are the "3D" things an artifact of some mailing list encoding thing, or
are they a mis-paste?

Andy
-- 
http://wingolog.org/

Re: [build error] ./.libs/libguile-2.0.so: undefined reference to `clock_getcpuclockid'

[Andy Wingo]

Hi Douglas,

On Tue 10 May 2011 20:16, Douglas Mencken  writes:

> To get clock_getcpuclockid, it is needed to link with librt, where
> this symbol is present

Can you check your config.log for mentions of clock_gettime ?

For example in mine I have:

  configure:25329: checking for library containing clock_gettime
  configure:25377: result: -lrt
  configure:25389: checking for clock_gettime
  configure:25389: result: yes
  configure:25389: checking for clock_settime
  configure:25389: result: yes

> I'm trying to build guile-v2.0.1-53-g8f6a4b2, and got the following errors:
>
>   CC   guile-guile.o
>   CCLD guile
> ./.libs/libguile-2.0.so: warning: the use of `tmpnam' is dangerous,
> better use `mkstemp'
> ./.libs/libguile-2.0.so: warning: gethostbyaddr is obsolescent, use
> getaddrinfo() instead.
> ./.libs/libguile-2.0.so: warning: gethostbyname is obsolescent, use
> getnameinfo() instead.
> ./.libs/libguile-2.0.so: undefined reference to `clock_getcpuclockid'
> collect2: ld returned 1 exit status
> make[3]: *** [guile] Error 1

Odd.  To have gotten here you had to have built libguile already, which
indeed should have linked to -lrt.  Can you grep your libguile/Makefile
for LIB_CLOCK_GETTIME ?

Is it perhaps that clock_getcpuclockid is in -lrt but clock_gettime is
in your libc?

Andy
-- 
http://wingolog.org/

Re: {debug,read,readline,print}-{set!,disable,enable}

[Andy Wingo]

On Fri 29 Apr 2011 14:12, Wolfgang J Moeller  writes:

> In fact, {debug,print,read}-set! are macros that want "option-name" to
> be a literal symbol, while {debug,read}-{en,dis}able are procedures
> indeed (apparently taking multiple arguments) that want the
> "option-name"[s] to be quoted symbol[s].

Indeed; nasty, but it's what we've got.  Fixed the docs.

> [Noticed while looking for something like V1 (debug-disable 'debug)
> that might speed up execution.]

It's spelled `--no-debug'; see "Invoking Guile".

  `--debug'
   Start with the debugging virtual machine engine.  Using the
   debugging VM will enable support for VM hooks, which are needed
   for tracing, breakpoints, and accurate call counts when profiling.
   The debugging VM is slower than the regular VM, though, by about
   10 percent.  *Note VM Hooks::, for more information.

   By default, the debugging VM engine is only used when entering an
   interactive session.  When executing a script with `-s' or `-c',
   the normal, faster VM is used by default.

  `--no-debug'
   Do not use the debugging VM engine, even when entering an
   interactive session.

Also note that git is about 10-20% faster than 2.0.1.

Andy
-- 
http://wingolog.org/

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Andy Wingo]

On Sun 15 May 2011 12:56, Hans Aberg  writes:

> On Mac OS X 10.6.7, compiled using Xcode Version 3.2.6 64-bit,
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, scm_init_guile() gives the
> error:
>
>   Failed to get stack base for current thread.

The code in question does this:

void
scm_init_guile ()
{
  struct GC_stack_base stack_base;
  
  if (GC_get_stack_base (&stack_base) == GC_SUCCESS)
scm_i_init_thread_for_guile (&stack_base,
 scm_i_default_dynamic_state);
  else
{
  fprintf (stderr, "Failed to get stack base for current thread.\n");
  exit (1);
}
}

As you can see we rely on libgc here, and so this is a libgc bug.  Can
you try a newer libgc, or if that still fails, bring it up on their
list?

Thanks,

Andy
-- 
http://wingolog.org/

Re: Guile with win32 cross compiling

[Andy Wingo]

Hi Volker,

Thanks for the report.

On Tue 17 May 2011 01:01, Volker Grabsch  writes:

> "fix-include-error-in-gen-scmconfig.patch"
> The patch re-introduces a change which I already proposed
> in my last patch: You can't use $(AM_CPPFLAGS) for the native
> build, because it adds "-I../lib" which means that 
> is taken from the local GNU-lib installation. The problem is
> that the GNU-lib in "lib/" has been configured for MinGW, not
> for the native system. So it performs some fixes which don't
> work on non-MinGW systems, leading to strange, unhelpful error
> messages. It took me quite some time to figure this out, mostly
> because I thought that this should have already been fixed.

H!  Yes, sorry for overlooking this part of your patch.  After
thinking for a while about it I agree with you.  I modified your patch
to add a comment.

> "remove-mingw-ifsock.patch"
> This patch fixes an issue that also appears on native MinGW
> build, because _S_IFSOCK simply isn't defined there. Note that
> this issue was already reported, but hasn't been fixed up to
> now, at least not in the stable-2.0 branch:
> http://lists.gnu.org/archive/html/guile-devel/2011-01/msg00183.html

I'll look at this when I'm back on the internet.

>   CC net_db.lo
> net_db.c:460:1: error: 'AI_ALL' undeclared here (not in a function)
> net_db.c:460:1: error: expression in static assertion is not an integer
> net_db.c:482:33: warning: 'struct addrinfo' declared inside parameter list 
> [enabled by default]

If your target does not have e.g. struct addrinfo, because it does not
have IPv6, then you need to configure with
ac_cv_type_struct_addrinfo=no.  Check your config.log.  Or should this
be working somehow?

There are other ac_cv_* for getaddrinfo and other routines.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Hans Aberg]

On 20 May 2011, at 12:11, Andy Wingo wrote:

>> On Mac OS X 10.6.7, compiled using Xcode Version 3.2.6 64-bit,
>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, scm_init_guile() gives the
>> error:
>> 
>>  Failed to get stack base for current thread.
> 
> The code in question does this:
> 
>void
>scm_init_guile ()
>{
>  struct GC_stack_base stack_base;
> 
>  if (GC_get_stack_base (&stack_base) == GC_SUCCESS)
>scm_i_init_thread_for_guile (&stack_base,
> scm_i_default_dynamic_state);
>  else
>{
>  fprintf (stderr, "Failed to get stack base for current thread.\n");
>  exit (1);
>}
>}
> 
> As you can see we rely on libgc here, and so this is a libgc bug.  Can
> you try a newer libgc, or if that still fails, bring it up on their
> list?

In what ways do you use it differently in guile-2.0.1? - It works in 
guile-2.0.0.

I was directed to use bdwgc-7_2alpha5-20110107, as gc-7.1 did not work on my 
platform.

Hans

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Hans Aberg]

On 20 May 2011, at 12:11, Andy Wingo wrote:

>> On Mac OS X 10.6.7, compiled using Xcode Version 3.2.6 64-bit,
>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, scm_init_guile() gives the
>> error:
>> 
>>  Failed to get stack base for current thread.
...
> As you can see we rely on libgc here, and so this is a libgc bug.  Can
> you try a newer libgc, or if that still fails, bring it up on their
> list?

On Mac OS X, one must call GC_init() (not necessary on GNU/Linux). Has that 
dropped out in guile-2.0.1?

Hans

Re: Guile with win32 cross compiling

[Volker Grabsch]

Hello Andy,

thanks for the quick reply and for accepting and cleaning up
my patches so far.

Andy Wingo schrieb:
> >   CC net_db.lo
> > net_db.c:460:1: error: 'AI_ALL' undeclared here (not in a function)
> > net_db.c:460:1: error: expression in static assertion is not an integer
> > net_db.c:482:33: warning: 'struct addrinfo' declared inside parameter list 
> > [enabled by default]
[...]
> If your target does not have e.g. struct addrinfo, because it does not
> have IPv6, then you need to configure with
> ac_cv_type_struct_addrinfo=no.  Check your config.log.  Or should this
> be working somehow?
> 
> There are other ac_cv_* for getaddrinfo and other routines.

Okay, so I'm trying to get along without this ugly "ac_cv_type_struct_addrinfo"
hack, hoping that the following error report will be more useful to you.


1) My first attempt is to enable threads via:

   ./configure --host=i686-pc-mingw32 --disable-shared --with-threads 
LIBS='-lunistring -lintl -liconv'

This leads to the attached (compressed) config.log:

config.log.with-threads.bz2

Make stops at this point:

---
  CC libguile_2.0_la-threads.lo
threads.c: In function 'to_timespec':
threads.c:245:15: error: dereferencing pointer to incomplete type
threads.c:246:15: error: dereferencing pointer to incomplete type
threads.c:253:15: error: dereferencing pointer to incomplete type
threads.c:254:15: error: dereferencing pointer to incomplete type
threads.c: In function 'launch_thread':
threads.c:974:3: warning: implicit declaration of function 'GC_pthread_detach' 
[-Wimplicit-function-declaration]
threads.c: In function 'scm_call_with_new_thread':
threads.c:1009:3: warning: implicit declaration of function 'GC_pthread_create' 
[-Wimplicit-function-declaration]
threads.c: In function 'scm_join_thread_timed':
threads.c:1188:18: error: storage size of 'ctimeout' isn't known
threads.c:1188:18: warning: unused variable 'ctimeout' [-Wunused-variable]
threads.c: In function 'fat_mutex_lock':
threads.c:1408:41: error: dereferencing pointer to incomplete type
threads.c:1409:36: error: dereferencing pointer to incomplete type
threads.c:1410:43: error: dereferencing pointer to incomplete type
threads.c: In function 'scm_lock_mutex_timed':
threads.c:1442:18: error: storage size of 'cwaittime' isn't known
threads.c:1442:18: warning: unused variable 'cwaittime' [-Wunused-variable]
threads.c: In function 'scm_try_mutex':
threads.c:1476:18: error: storage size of 'cwaittime' isn't known
threads.c:1476:18: warning: unused variable 'cwaittime' [-Wunused-variable]
threads.c: In function 'scm_unlock_mutex_timed':
threads.c:1619:18: error: storage size of 'cwaittime' isn't known
threads.c:1619:18: warning: unused variable 'cwaittime' [-Wunused-variable]
threads.c: In function 'scm_timed_wait_condition_variable':
threads.c:1723:18: error: storage size of 'waittime' isn't known
threads.c:1723:18: warning: unused variable 'waittime' [-Wunused-variable]
threads.c: In function 'scm_pthread_cond_timedwait':
threads.c:1924:3: warning: passing argument 3 of 'pthread_cond_timedwait' from 
incompatible pointer type [enabled by default]
/home/vog/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include/pthread.h:1069:31:
 note: expected 'const struct timespec *' but argument is of type 'const struct 
scm_t_timespec *'
---



2) My second attempt is to build without threading:

This leads to a slightly different config.log which I also attached:

config.log.without-threads.bz2

Make then stops at the same point with just a few less error messages:

---
  CC libguile_2.0_la-threads.lo
threads.c: In function 'to_timespec':
threads.c:245:15: error: dereferencing pointer to incomplete type
threads.c:246:15: error: dereferencing pointer to incomplete type
threads.c:253:15: error: dereferencing pointer to incomplete type
threads.c:254:15: error: dereferencing pointer to incomplete type
threads.c: In function 'scm_cancel_thread':
threads.c:1124:7: warning: statement with no effect [-Wunused-value]
threads.c: In function 'scm_join_thread_timed':
threads.c:1188:18: error: storage size of 'ctimeout' isn't known
threads.c:1188:18: warning: unused variable 'ctimeout' [-Wunused-variable]
threads.c: In function 'fat_mutex_lock':
threads.c:1408:41: error: dereferencing pointer to incomplete type
threads.c:1409:36: error: dereferencing pointer to incomplete type
threads.c:1410:43: error: dereferencing pointer to incomplete type
threads.c: In function 'scm_lock_mutex_timed':
threads.c:1442:18: error: storage size of 'cwaittime' isn't known
threads.c:1442:18: warning: unused variable 'cwaittime' [-Wunused-variable]
threads.c: In function 'scm_try_mutex':
threads.c:1476:18: error: storage size of 'cwaittime' isn't known
threads.c:1476:18: warning: unused variable 'cwaittime' [

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Andy Wingo]

On Fri 20 May 2011 13:31, Hans Aberg  writes:

> On 20 May 2011, at 12:11, Andy Wingo wrote:
>
>>> On Mac OS X 10.6.7, compiled using Xcode Version 3.2.6 64-bit,
>>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, scm_init_guile() gives the
>>> error:
>>> 
>>>  Failed to get stack base for current thread.
> ...
>> As you can see we rely on libgc here, and so this is a libgc bug.  Can
>> you try a newer libgc, or if that still fails, bring it up on their
>> list?
>
> On Mac OS X, one must call GC_init() (not necessary on GNU/Linux). Has
> that dropped out in guile-2.0.1?

I really have no idea.  As you see in 2.0.1 we rely on libgc for
detecting stack boundaries in the non-scm_with_guile case, as is
appropriate I think.  As for GC_init() I don't know, and would be
surprised if that were the case.

Andy
-- 
http://wingolog.org/

Re: Guile with win32 cross compiling

[Andy Wingo]

On Fri 20 May 2011 14:48, Jan Nieuwenhuizen  writes:

> Volker Grabsch writes:
>
>> 1) My first attempt is to enable threads via:
>
> Just to remind you that we have an automated working mingw cross build
> setup here
>
> https://github.com/janneke/gub

Cool :-)

Just to remind *you* that I have outstanding questions regarding your
patches (3/5, 4/5, and 5/5) ;-)

Cheers,

Andy
-- 
http://wingolog.org/

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Hans Aberg]

On 20 May 2011, at 15:10, Andy Wingo wrote:

 On Mac OS X 10.6.7, compiled using Xcode Version 3.2.6 64-bit,
 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, scm_init_guile() gives the
 error:
 
 Failed to get stack base for current thread.
>> ...
>>> As you can see we rely on libgc here, and so this is a libgc bug.  Can
>>> you try a newer libgc, or if that still fails, bring it up on their
>>> list?
>> 
>> On Mac OS X, one must call GC_init() (not necessary on GNU/Linux). Has
>> that dropped out in guile-2.0.1?
> 
> I really have no idea.  As you see in 2.0.1 we rely on libgc for
> detecting stack boundaries in the non-scm_with_guile case, as is
> appropriate I think.  As for GC_init() I don't know, and would be
> surprised if that were the case.

There is a comment in in libguile/gc.c suggesting it isn't called, there is:

void
scm_storage_prehistory ()
{
  GC_all_interior_pointers = 0;
  GC_set_free_space_divisor (scm_getenv_int ("GC_FREE_SPACE_DIVISOR", 3));

  GC_INIT ();

#if (! ((defined GC_VERSION_MAJOR) && (GC_VERSION_MAJOR >= 7))) \
&& (defined SCM_I_GSC_USE_PTHREAD_THREADS)
  /* When using GC 6.8, this call is required to initialize thread-local
 freelists (shouldn't be necessary with GC 7.0).  */
  GC_init ();
#endif
...
}

The presumption is wrong, because it does not work on Mac OS X without calling 
GC_init() - I have tried.

Hans

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Andy Wingo]

Hello,

On Fri 20 May 2011 15:39, Hans Aberg  writes:

> There is a comment in in libguile/gc.c suggesting it isn't called, there is:
>
> void
> scm_storage_prehistory ()
> {
>   GC_all_interior_pointers = 0;
>   GC_set_free_space_divisor (scm_getenv_int ("GC_FREE_SPACE_DIVISOR", 3));
>
>   GC_INIT ();
>
> #if (! ((defined GC_VERSION_MAJOR) && (GC_VERSION_MAJOR >= 7))) \
> && (defined SCM_I_GSC_USE_PTHREAD_THREADS)
>   /* When using GC 6.8, this call is required to initialize thread-local
>  freelists (shouldn't be necessary with GC 7.0).  */
>   GC_init ();
> #endif
> ...
> }
>
> The presumption is wrong, because it does not work on Mac OS X without 
> calling GC_init() - I have tried.

Did you enable threads? `grep PTHREAD scmconfig.h` to check.

Here is the current definition of GC_INIT ():

/* Portable clients should call this at the program start-up.  More */
/* over, some platforms require this call to be done strictly from the  */
/* primordial thread.   */
#define GC_INIT() { GC_INIT_CONF_DONT_EXPAND; /* pre-init */ \
GC_INIT_CONF_FORCE_UNMAP_ON_GCOLLECT; \
GC_INIT_CONF_MAX_RETRIES; \
GC_INIT_CONF_FREE_SPACE_DIVISOR; \
GC_INIT_CONF_FULL_FREQ; \
GC_INIT_CONF_TIME_LIMIT; \
GC_INIT_CONF_MAXIMUM_HEAP_SIZE; \
GC_init(); /* real GC initialization */ \
GC_INIT_CONF_ROOTS; /* post-init */ \
GC_INIT_CONF_IGNORE_WARN; \
GC_INIT_CONF_INITIAL_HEAP_SIZE; }

So you see it does GC_init().  That was not always the case in previous
versions, AFAIK.

Andy
-- 
http://wingolog.org/

Re: guile 2.0.1 crash compiling gnome startup code

[Andy Wingo]

Hi Jeff,

On Wed 11 May 2011 15:58, Jeff Sparkes  writes:

> [jsparkes ~]$ gdb guile core
> GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/local/bin/guile...done.
> [New Thread 8947]
>
> warning: Can't read pathname for load map: Input/output error.
> Reading symbols from /usr/local/lib/libguile-2.0.so.22...done.
> Loaded symbols for /usr/local/lib/libguile-2.0.so.22
> Reading symbols from /lib/i386-linux-gnu/libcrypt.so.1...(no debugging 
> symbols found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libcrypt.so.1
> Reading symbols from /lib/i386-linux-gnu/libm.so.6...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libm.so.6
> Reading symbols from /lib/i386-linux-gnu/libpthread.so.0...(no debugging 
> symbols found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libpthread.so.0
> Reading symbols from /lib/i386-linux-gnu/libc.so.6...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libc.so.6
> Reading symbols from /usr/local/lib/libgc.so.1...done.
> Loaded symbols for /usr/local/lib/libgc.so.1
> Reading symbols from /usr/lib/libffi.so.5...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libffi.so.5
> Reading symbols from /lib/i386-linux-gnu/librt.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/i386-linux-gnu/librt.so.1
> Reading symbols from /usr/lib/libunistring.so.0...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libunistring.so.0
> Reading symbols from /usr/lib/libgmp.so.3...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libgmp.so.3
> Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libltdl.so.7
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/ld-linux.so.2
> Reading symbols from /lib/i386-linux-gnu/libdl.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libdl.so.2
> Reading symbols from /lib/i386-linux-gnu/libgcc_s.so.1...(no debugging 
> symbols found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libgcc_s.so.1
> Reading symbols from /usr/lib/i386-linux-gnu/gconv/ISO8859-1.so...(no 
> debugging symbols found)...done.
> Loaded symbols for /usr/lib/i386-linux-gnu/gconv/ISO8859-1.so
> Reading symbols from /usr/local/lib/libguile-gnome-gobject-2.so.0...done.
> Loaded symbols for /usr/local/lib/libguile-gnome-gobject-2.so.0
> Reading symbols from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0...(no 
> debugging symbols found)...done.
> Loaded symbols for /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> Reading symbols from /usr/lib/i386-linux-gnu/libgthread-2.0.so.0...(no 
> debugging symbols found)...done.
> Loaded symbols for /usr/lib/i386-linux-gnu/libgthread-2.0.so.0
> Reading symbols from /lib/i386-linux-gnu/libglib-2.0.so.0...(no debugging 
> symbols found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libglib-2.0.so.0
> Reading symbols from /usr/lib/libguile.so.17...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libguile.so.17

^^^ Ding ding ding!  We have a winner! ;-)

> Reading symbols from /lib/i386-linux-gnu/libpcre.so.3...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/i386-linux-gnu/libpcre.so.3
> Core was generated by `guile /home/jsparkes/toolbar.scm'.
> Program terminated with signal 11, Segmentation fault.
> #0  scm_cell () at /usr/include/libguile/inline.h:127
> 127 *freelist = SCM_FREE_CELL_CDR (*freelist);

Indeed this is guile 1.8 code, which obviously won't work in the same
image as Guile 2.0 code.

The solution is to compile guile-gnome against Guile 2.0.

Regards,

Andy
-- 
http://wingolog.org/

Re: Guile 2.0.1: scm_init_guile() broken on Mac OS X 10.6.7

[Hans Aberg]

On 20 May 2011, at 15:58, Andy Wingo wrote:

> Did you enable threads? `grep PTHREAD scmconfig.h` to check.

$ grep PTHREAD libguile/scmconfig.h
#define SCM_USE_PTHREAD_THREADS 1 /* 0 or 1 */
/* Define to 1 if need braces around PTHREAD_ONCE_INIT (for Solaris). */
#define SCM_NEED_BRACES_ON_PTHREAD_ONCE_INIT 0 /* 0 or 1 */
/* Define to 1 if need braces around PTHREAD_MUTEX_INITIALIZER
#define SCM_NEED_BRACES_ON_PTHREAD_MUTEX_INITIALIZER 0 /* 0 or 1 */
#define SCM_HAVE_GC_PTHREAD_CANCEL 0 /* 0 or 1 */
#define SCM_HAVE_GC_PTHREAD_EXIT 0 /* 0 or 1 */
#define SCM_HAVE_GC_PTHREAD_SIGMASK 0 /* 0 or 1 */

> Here is the current definition of GC_INIT ():
> 
>/* Portable clients should call this at the program start-up.  More */
>/* over, some platforms require this call to be done strictly from the  */
>/* primordial thread.   */
>#define GC_INIT() { GC_INIT_CONF_DONT_EXPAND; /* pre-init */ \
>GC_INIT_CONF_FORCE_UNMAP_ON_GCOLLECT; \
>GC_INIT_CONF_MAX_RETRIES; \
>GC_INIT_CONF_FREE_SPACE_DIVISOR; \
>GC_INIT_CONF_FULL_FREQ; \
>GC_INIT_CONF_TIME_LIMIT; \
>GC_INIT_CONF_MAXIMUM_HEAP_SIZE; \
>GC_init(); /* real GC initialization */ \
>GC_INIT_CONF_ROOTS; /* post-init */ \
>GC_INIT_CONF_IGNORE_WARN; \
>GC_INIT_CONF_INITIAL_HEAP_SIZE; }
> 
> So you see it does GC_init().  That was not always the case in previous
> versions, AFAIK.

And adding it does not help.

Hans

Re: [build error] ./.libs/libguile-2.0.so: undefined reference to `clock_getcpuclockid'

[Andy Wingo]

On Fri 20 May 2011 12:07, Andy Wingo  writes:

> Hi Douglas,
>
> On Tue 10 May 2011 20:16, Douglas Mencken  writes:
>
>> To get clock_getcpuclockid, it is needed to link with librt, where
>> this symbol is present

Does this patch fix it for you?

>From 5ad05b93a3f02be7c66fbab9c49e23ca314b7c33 Mon Sep 17 00:00:00 2001
From: Andy Wingo 
Date: Fri, 20 May 2011 18:48:33 +0200
Subject: [PATCH] check for clock_getcpuclockid in gl_CLOCK_TIME

* acinclude.m4 (gl_CLOCK_TIME): It could be that clock_gettime is in
  libc but clock_getcpuclockid is not, so check for that explicitly.
---
 acinclude.m4 |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index ba8b090..5bd1ced 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -529,8 +529,14 @@ AC_DEFUN([gl_CLOCK_TIME],
   AC_SUBST([LIB_CLOCK_GETTIME])
   gl_saved_libs=$LIBS
 AC_SEARCH_LIBS([clock_gettime], [rt posix4],
-   [test "$ac_cv_search_clock_gettime" = "none required" ||
-LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime])
-AC_CHECK_FUNCS([clock_gettime clock_settime])
+   [if test "$ac_cv_search_clock_gettime" = "none required"; 
then
+  AC_SEARCH_LIBS([clock_getcpuclockid], [rt posix4],
+ [test "$ac_cv_search_clock_getcpuclockid" 
= "none required" \
+  || 
LIB_CLOCK_GETTIME=$ac_cv_search_clock_getcpuclockid],
+ 
[LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime])
+else
+  LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime
+fi])
+AC_CHECK_FUNCS([clock_gettime clock_settime clock_getcpuclockid])
   LIBS=$gl_saved_libs
 ])
-- 
1.7.5.1


-- 
http://wingolog.org/

Re: guile-2.0.0 fails to build without threads

[Marco Maggi]

Andy Wingo wrote:
> Thanks.  You  seem to  be running on  system in  which the
> stackgrows   up.Isthat   thecase?Check
> libguile/scmconfig.h and config.log.

Yes, I have:

#define SCM_STACK_GROWS_UP 1 /* 0 or 1 */

in "scmconfig.h"; my system is just a i686-pc-linux-gnu.

> You mention in your original report:
> CFLAGS=3D'-O3 -march=3Di686 -mtune=3Di686'

> Are  the "3D"  things  an artifact  of  some mailing  list
> encoding thing, or are they a mis-paste?

They were  just "=" characters, but while  pasting them into
Emacs from  a terminal  (?) caused them  to be  converted to
"=3D" for some reason unknown  to me.  I am fairly sure that
that  command line  came from  a build  script (bash)  I use
every time to rebuild Guile and there are no errors in it.
-- 
Marco Maggi

Re: Guile with win32 cross compiling

[Jan Nieuwenhuizen]

Volker Grabsch writes:

> 1) My first attempt is to enable threads via:

Just to remind you that we have an automated working mingw cross build
setup here

https://github.com/janneke/gub

with guile-specific recipe and patches up at

https://github.com/janneke/gub/blob/guile-2.0/gub/specs/guile.py
https://github.com/janneke/gub/tree/guile-2.0/patches

Jan

Greetings, Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

Re: Guile with win32 cross compiling

[Volker Grabsch]

Jan Nieuwenhuizen schrieb:
> https://github.com/janneke/gub/blob/guile-2.0/gub/specs/guile.py
> https://github.com/janneke/gub/tree/guile-2.0/patches

Thanks for pointing me to this project. This looks really
promising and I would be glad for learning from that.

1) The pthread issue

As far as I can see, you have patched libgc to support pthreads
under MinGW. You forward-ported those patches from libgc-6.8 to 7.2,
so I'm wondering why those patches didn't make it into upstream
(i.e. the official libgc project) during that time. Are there any
issues with those patches that I should know about?

Also, have you actually offered these patches to upstream? If so,
what's the URL to their bug tracker, or mailing list archive, where
this issue has been discussed? I haven't been able to find any such
information in neither the *.py file not the patch files.

2) The struct_timespec / ipv6 / etc. issues

It seems that you solve those issues using an even uglier hack
than I did. I'm wondering why it is necessary to manipulate the
config.cache, as providing those variables as ./configure paramters
worked quite well for me.

Moreover, is this a sensible thing to do anyway? Shouldn't we try
to fix the configure.ac to make it more portable and to make it
properly detect those MinGW things in the first place?


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---

Re: guile-2.0.0 fails to build without threads

[Mark H Weaver]

Marco Maggi  writes:
> Andy Wingo wrote:
>> You mention in your original report:
>> CFLAGS=3D'-O3 -march=3Di686 -mtune=3Di686'
>
>> Are  the "3D"  things  an artifact  of  some mailing  list
>> encoding thing, or are they a mis-paste?
>
> They were  just "=" characters, but while  pasting them into
> Emacs from  a terminal  (?) caused them  to be  converted to
> "=3D" for some reason unknown  to me.

"=" is encoded as "=3D" when using MIME's "quoted-printable" content
transfer encoding , which
is commonly used to encode 8-bit messages for email.  (0x3D is the ASCII
value of '=').  Marco's email should have included the following header,
but didn't:

  Content-Transfer-Encoding: quoted-printable

Since the above header was not present, our email clients did not know
to decode the quoted-printable escapes.  Emacs users could have done:

  M-x quoted-printable-decode-region

to decode the message manually.

Best,
 Mark