guile-2.0.0 segmentation fault on MacOS X 10.6.

All, I've built guile-2.0.0 and tried it out, I got segmentation fault running guile, the shell script starting the interpreter. Is this a known problem? steve

guile-1.8.0 make error.

Here is the last part of make.log __ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -D_THREAD_SAFE -g -O2 - Wall -Wmissing-prototypes -Werror -MT libguile_la-modules.lo -MD -MP - MF .deps/libguile_la-modules.Tpo -c modules.c -o libguile_la- modules.o >/dev/null 2>&1 if /bin/sh ../libtool --tag=CC -

guile-1.8.0 configure warnings for MacOS X 10.4

here is the warning: ./configure --prefix=/usr --with-threads checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $

A solution to pthread_getattr_np on MacOS X and potentially others.

One problem that I see in porting Guile to MacOS X is the function get_thread_stack_base. Since pthread_getattr_np is not portable, we need a better approach. Here is what I did: I defined a macro PTHREAD_GET_STACKSIZE(size, start, end) and used that in get_thread_stack_base function. I the

CVS guile build error on MacOS X.

It seems like the on MacOS X 10.4, the configure decided guile need locale.h, but certain definitions are missing. I got the following errors: i18n.c: In function 'scm_nl_langinfo': i18n.c:1449: error: 'GROUPING' undeclared (first use in this function) i18n.c:1449: error: (Each undeclared ide

guile-1.8.4 build failed on Leopard.

Hi, I was building guile-1.8.4 on my macbook pro, and I found the linking problem. Here is the configure command I typed: ./configure --prefix=/usr --with-threads --enable-shared and here is the make.log tail: (cd .libs && gcc -g -O2 -c -fno-builtin "guileS.c") rm -f .libs/guileS.c .libs/g

Re: guile-1.8.4 build failed on Leopard.

thanks, I found the bug last night, it was libtool's ltdl.h didn't get generated properly. I'll let libtool people know about it. steve On Apr 11, 2008, at 6:21 AM, Marijn Schouten (hkBst) wrote: -BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven Wu wrote: | Hi, | | I was

git clone guile 1.9 build problem on MacOS X 10.5.2

Hi, I was building guile 1.9 from git clone src, and I run into the following problems: $ ./autogen.sh $ ./configure --prefix=/usr --enable-shared --enable-maintainer-mode -- enable-threads ... === configuring in guile-readline (/Users/wus/local/src/gnu/guile/ guile-readline) configure: run

Re: git clone guile 1.9 build problem on MacOS X 10.5.2

config.log: lispdir='${datarootdir}/emacs/site-lisp' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' lt_ECHO='/bin/echo' mandir='${datarootdir}/man' mkdir_p='$(top_builddir)/build-aux/install-sh -c -d' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/usr' program_transform

Re: git clone guile 1.9 build problem on MacOS X 10.5.2

silly me, here we go: configure:2881: gccconftest.c >&5 conftest.c:5: error: missing terminating " character conftest.c:7: error: missing terminating " character configure:2884: $? = 1 configure:2922: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "guile-re

Re: git clone guile 1.9 build problem on MacOS X 10.5.2

looks like the problems are in the configure file, where I found the following: PACKAGE_VERSION='-n 1.9.0 ' PACKAGE_STRING='guile-readline -n 1.9.0 ' If I changed them by hand, the problem went away. steve

using libltdl from 2.2.x requires libtool 2.2.x to link against

Per Ralf Wildenhues from libtool team. It seems that libtool generated from autogen.sh is incorrect for both 1.8.4 and 1.9.0 if using 2.2.x libltdl. The result will be a linking error "symbol _lt__PROGRAM__LTX_preloaded_symbols not found." Even copy 2.2.x libtool, it is still wrong, since t

Re: git clone guile 1.9 build problem on MacOS X 10.5.2

track down where the problem occurred: configure.in 3: m4_esyscmd(. ../GUILE-VERSION && echo -n $ {GUILE_VERSION})) It looks like MacOS X /bin/sh did not know -n flag, and it generated '-n 1.9.0 ' steve