[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 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

in their 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 ./ (adjusted for glibtoolize):

> ./
autoreconf: Entering directory `.'
autoreconf: 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 to turn on gettext stuff. But, just in case it turns out okay, I let run anyway....

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

And then ./ fails with: 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 (because that's what version `gettext --version` prints for me). Now, autopoint runs, and a po/ directory is created. But, ./ later fails again with: AM_GNU_GETTEXT used but `po' not in SUBDIRS
  autoreconf: automake failed with exit status: 1

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

At this point I lost interest, since commenting out AM_GNU_GETTEXT 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).

reply via email to

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