guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

building cvs guile on Mac OS X 10.4


From: Richard Todd
Subject: building cvs guile on Mac OS X 10.4
Date: 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.


Problem 2.*****
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.


Problem 3:******
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.

Problem 4:******
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...

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 char*)
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)

Problem 5:******
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 compile errors.

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.

Problem 6.******
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.


END RESULT:
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]