building cvs guile on Mac OS X 10.4

building cvs guile on Mac OS X 10.4

[Richard Todd]

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.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Neil Jerram]

Richard Todd wrote:
> 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, [...]
> 
> Problem 4:******
> Lots of compile warnings, [...]
> 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 *)

Thanks; I've fixed all these in CVS.

> unif.c 2701  cast &rank to (ssize_t *)

For this one I changed the declaration of rank from size_t to ssize_t. 
I think this is right, as otherwise the (rank < 0) check wouldn't make 
sense on platforms where size_t is unsigned, but if anyone else knows 
better please say.  (Or if it introduces any new warnings ... :-( )

> socket.c several more (most involving addr_len)

Send 'em on!

	Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Richard Todd]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On May 12, 2005, at 1:39 AM, Neil Jerram wrote:
>
>
>> socket.c several more (most involving addr_len)
>>
>
> Send 'em on!
>
>     Neil


Thanks for applying those.  Here (attached) are the remaining changes  
I need against CVS guile to build without warnings.  (I would still  
like to see some of the autoconf/automake stuff addressed--I may have  
some time to try to work that out this weekend, but I'm no autotools  
expert).




[-- Attachment #2: guile_warnings.diff --]
[-- Type: application/octet-stream, Size: 2948 bytes --]

Index: libguile/socket.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/socket.c,v
retrieving revision 1.112
diff -u -r1.112 socket.c
--- libguile/socket.c	27 Feb 2005 23:50:30 -0000	1.112
+++ libguile/socket.c	12 May 2005 23:44:39 -0000
@@ -369,7 +369,7 @@
   if (af == AF_INET)
     return scm_from_ulong (ntohl (*(scm_t_uint32 *) dst));
   else
-    return scm_from_ipv6 ((char *) dst);
+    return scm_from_ipv6 ((unsigned char *) dst);
 }
 #undef FUNC_NAME
 #endif
@@ -401,7 +401,7 @@
   if (af == AF_INET)
     *(scm_t_uint32 *) addr6 = htonl (SCM_NUM2ULONG (2, address));
   else
-    scm_to_ipv6 (addr6, address);
+    scm_to_ipv6 ((unsigned char*)addr6, address);
   if (inet_ntop (af, &addr6, dst, sizeof dst) == NULL)
     SCM_SYSERROR;
   return scm_from_locale_string (dst);
@@ -494,7 +494,7 @@
   ioptname = scm_to_int (optname);
 
   fd = SCM_FPORT_FDES (sock);
-  if (getsockopt (fd, ilevel, ioptname, (void *) optval, &optlen) == -1)
+  if (getsockopt (fd, ilevel, ioptname, (void *) optval, (unsigned int*)&optlen) == -1)
     SCM_SYSERROR;
 
   if (ilevel == SOL_SOCKET)
@@ -1004,7 +1004,7 @@
   sock = SCM_COERCE_OUTPORT (sock);
   SCM_VALIDATE_OPFPORT (1, sock);
   fd = SCM_FPORT_FDES (sock);
-  newfd = accept (fd, addr, &addr_size);
+  newfd = accept (fd, addr, (unsigned int *)&addr_size);
   if (newfd == -1)
     SCM_SYSERROR;
   newsock = SCM_SOCK_FD_TO_PORT (newfd);
@@ -1028,7 +1028,7 @@
   sock = SCM_COERCE_OUTPORT (sock);
   SCM_VALIDATE_OPFPORT (1, sock);
   fd = SCM_FPORT_FDES (sock);
-  if (getsockname (fd, addr, &addr_size) == -1)
+  if (getsockname (fd, addr, (unsigned int*)&addr_size) == -1)
     SCM_SYSERROR;
   return scm_addr_vector (addr, addr_size, FUNC_NAME);
 }
@@ -1050,7 +1050,7 @@
   sock = SCM_COERCE_OUTPORT (sock);
   SCM_VALIDATE_OPFPORT (1, sock);
   fd = SCM_FPORT_FDES (sock);
-  if (getpeername (fd, addr, &addr_size) == -1)
+  if (getpeername (fd, addr, (unsigned int*)&addr_size) == -1)
     SCM_SYSERROR;
   return scm_addr_vector (addr, addr_size, FUNC_NAME);
 }
@@ -1200,7 +1200,7 @@
   addr->sa_family = AF_UNSPEC;
   SCM_SYSCALL (rv = recvfrom (fd, buf + offset,
 			      cend - offset, flg,
-			      addr, &addr_size));
+			      addr, (unsigned int *)&addr_size));
   scm_i_string_stop_writing ();
 
   if (rv == -1)
Index: srfi/srfi-1.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/srfi/srfi-1.c,v
retrieving revision 1.35
diff -u -r1.35 srfi-1.c
--- srfi/srfi-1.c	6 May 2005 23:57:21 -0000	1.35
+++ srfi/srfi-1.c	12 May 2005 23:44:44 -0000
@@ -1223,9 +1223,10 @@
 {
   long i;
 
+  SCM elt = 0;
   for (i = SCM_SIMPLE_VECTOR_LENGTH (argv) - 1; i >= 1; i--)
     {
-      SCM elt = SCM_SIMPLE_VECTOR_REF (argv, i);
+      elt = SCM_SIMPLE_VECTOR_REF (argv, i);
       long elt_len;
 
       if (!(scm_is_null (elt) || scm_is_pair (elt)))

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Kevin Ryde]

Richard Todd <rwtodd@mac.com> writes:
>
> -  if (getsockopt (fd, ilevel, ioptname, (void *) optval, &optlen) == -1)
> +  if (getsockopt (fd, ilevel, ioptname, (void *) optval, (unsigned int*)&optlen) == -1)

It'd be better to change to socklen_t for these, even if there has to
be a fallback for old systems.

> +  SCM elt = 0;

I don't think 0 is valid when SCM is a struct under certain debug
options.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Neil Jerram]

Richard Todd wrote:

> (I would still  
> like to see some of the autoconf/automake stuff addressed--I may have  
> some time to try to work that out this weekend, but I'm no autotools  
> expert).

Sure; I was just picking off the easy ones first.  (And unfortunately 
I'm no autotools expert, either.  It might be worth Googling to see if 
other programs have already solved the same problems, especially the 
glibtoolize one.)

	Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Neil Jerram]

Richard Todd wrote:
> 
> 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.

Actually, HEAD CVS does not call libtoolize anymore (since 8th March). 
Were you building with a CVS snapshot from before this date?

Regards,
	Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Neil Jerram]

Neil Jerram wrote:
> 
> Actually, HEAD CVS does not call libtoolize anymore (since 8th March). 
> Were you building with a CVS snapshot from before this date?

Sorry, ignore that.  I see now that autogen.sh calls autoreconf, and 
autoreconf decides to call libtoolize.  Problem still open.

	Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Richard Todd]

On May 14, 2005, at 8:07 AM, Neil Jerram wrote:
> Sorry, ignore that.  I see now that autogen.sh calls autoreconf,  
> and autoreconf decides to call libtoolize.  Problem still open.

Right.  And I have seen projects put something like:

if [ `uname -s` = "Darwin" ] ; then
   export LIBTOOLIZE=glibtoolize
fi

in their autogen.sh equivalents.  Maybe that's the best that can be  
done, from a guile perspective.  I've also seen people suggesting  
that mac owners make a symlink so that a typical 'libtoolize' is  
available.


***
Something else that I would consider a bug in the Mac setup, but  
don't know how to fix:

gcc looks in /usr/local/include before /usr/include, like it should.   
However, ld looks in /usr/lib before /usr/local/lib.  So, my GNU  
readline in /usr/local is picked up for complation but not linking,  
unless I wedge a '-L/usr/local/lib' into my LDFLAGS.  So, I don't  
know if you want workarounds like this in your build scripts (I  
wouldn't want them, if I were you).  But on the other hand I bet this  
isn't fixed any time soon.  Maybe I'll put together a document on  
what Mac users should do.  The readline-clone, libedit, that is  
installed by default, does not work for building guile.

I guess another option would be to try to make guile build against  
the subset of readline that is in libedit, but based on the number of  
undefined symbols, I bet that's not too easy to do without losing  
functionality.


***
The whole gettext thing throws me.  Here's more information.  Let's  
start with a plain CVS guile, and run ./autogen.sh (adjusted for  
glibtoolize):

 > ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext

I have gettext, but it decides not to use it.  looking at my  
autoreconf (version 2.59), I see that it's expecting to find  
AM_GNU_GETTEXT_VERSION in configure.in to turn on gettext stuff.   
But, just in case it turns out okay, I let autogen.sh run anyway....

I note this warning pops up later in the output:
    autoreconf: configure.in: AM_GNU_GETTEXT is used, but not  
AM_GNU_GETTEXT_VERSION

And then ./autogen.sh fails with:
   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS
   autoreconf: automake failed with exit status: 1

So, I add AM_GNU_GETTEXT_VERSION([0.13]) to configure.in (because  
that's what version `gettext --version` prints for me).  Now,  
autopoint runs, and a po/ directory is created.  But, ./autogen.sh  
later fails again with:
   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS
   autoreconf: automake failed with exit status: 1

So, I add 'po' to SUBDIRS in Makefile.am, and po/Makefile to the  
outputs of configure.in, but quickly found out that po/ has a  
Makefile.in.in instead of a Makefile.in.

At this point I lost interest, since commenting out AM_GNU_GETTEXT in  
configure.in builds a working guile for me.  Surely someone out there  
knows something about gettext, and can resolve it in much less time  
than I could.  Google had some conflicting things to say about  
whether a special sed cript should be inserted into AC_OUTPUT, but  
that seemed out of date.  Regardless, I suppose the SUBDIRS and  
Makefile entries for gettext should only be conditionally added in  
the final solution, based on whether gettext was found?

(oddly enough, a side-effect of getting gettext to work this far also  
shoved -L/usr/local/lib into my LDFLAGS, so if I'm ever able to  
compile against gettext I won't happen to need that workaround for  
readline anymore.  I guess I'm glad it failed or I never would have  
noticed that /usr/local oddity).





_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: building cvs guile on Mac OS X 10.4

[Kevin Ryde]

Richard Todd <rwtodd@mac.com> writes:
>
> I've also seen people suggesting  
> that mac owners make a symlink so that a typical 'libtoolize' is  
> available.

Getting it fixed in macos is better than having every project in the
world make a special case.

> gcc looks in /usr/local/include before /usr/include, like it should.   
> However, ld looks in /usr/lib before /usr/local/lib.

:( Pretty dodgy.

> So, my GNU  
> readline in /usr/local is picked up for complation but not linking,  
> unless I wedge a '-L/usr/local/lib' into my LDFLAGS.  So, I don't  
> know if you want workarounds like this in your build scripts

It must affect every package using readline that you attempt to build,
so a special case in guile won't really help.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel