[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: building cvs guile on Mac OS X 10.4
From: |
Richard Todd |
Subject: |
Re: building cvs guile on Mac OS X 10.4 |
Date: |
Sat, 14 May 2005 11:32:18 -0500 |
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).