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).