[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
building cvs guile on Mac OS X 10.4
building cvs guile on Mac OS X 10.4
Sun, 8 May 2005 02:36:01 -0500
I hadn't built guile from CVS in many months, so I wanted to give it
a try on my fresh new OS X install, to see how much pain there would
be. Here were the issues I ran across. Sorry to say that most of my
workarounds are just that--workarounds.
Someone that understands automake/autoconf better than me would need
to find better solutions.
Problem 1: ******
./autogen.sh says something upfront like "I'm not going to use
gettext", but then I get a complaint about AM_GNU_GETTEXT not being
in the m4 library.
So, first I tried installing gettext, and adding -I/usr/local/share/
aclocal to the aclocal call. That got me past the AM_GNU_GETTEXT
problem, but later I got a complaint that I was using gettext, but
'po' wasn't in SUBDIRS. I decided that, rather than try to fix this,
I'll comment out the AM_GNU_GETTEXT from configure.in.
Libtoolize not found. Turns out OS X calls it glibtoolize, but
nothing in ./autogen.sh figured this out.
My solution: export LIBTOOLIZE=glibtoolize
I assume there is a better solution.
Mac OS X does not support recursive mutexes. Guile uses them. Just
in case guile didn't depend on them being recursive, I changed the
#define for PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP so that it mapped
to a normal, non-recursive mutex. This compiled, but guile hung, and
while I didn't bother looking, I assume it was deadlocked. So, I
gave up and compiled out threading.
temp. solution: ./configure --without-threads
I looked around google, and other OS X ports have hit this problem.
Looks like some of them may have implemented their own recursive locks.
Lots of compile warnings, and by default guile is building with -
Werror. I can't believe all of these are OS X-specific. But, maybe
So, simply assuming that the code must be right, I added casts
everywhere there was a complaint.
I made a point of writing most of them down:
gh_data.c line 131 cast to scm_t_int8 *
hash.c line 114 cast first arg to const unsigned char *
load.c 377 dropped the' >= 1' that seemed extraneous...
rdelim.c 207 set slen to 0 so it wouldn't be uninitialized
srfi-13.c 2476 cast return of scm_i_writable_chars to (unsigned
strports.c 109 cast dst to (unsigned char *)
297 changed cast to (unsigned char *)
unif.c 2701 cast &rank to (ssize_t *)
socket.c several more (most involving addr_len)
OS X has a /usr/include/readline/readline.h which is not GNU
readline, and is not source-compatible with GNU readline. So, I got
I installed GNU readline (had to make one change to their package
which I emailed to their mailing list), and changed Makefile.am in
guile-readline to point to /usr/local/include and /usr/local/lib.
Obviously this isn't the right solution. I guess you would want ./
configure to figure out that the OS X version is not sufficient for
guile to build.
srfi/srfi-1.c line 1228 warning that elt may be used without being
initialized. And indeed it looks like it could, if the 'goto' later
in the function is invoked, but the for loop had never run. So, I
made the declaration of 'SCM elt = 0' on the line above the for loop
to make the compiler happy.
If the case the compiler was worried about can actually happen,
though, this change would not help any.
I have built what appears to be a functional guile (minus threads).
I haven't played with it much, but readline support does appear to
work, and a couple scripts I tried ran without incident.
If you need any more information, or would like me to try patches,
I'd be happy to do that.
- building cvs guile on Mac OS X 10.4,
Richard Todd <=