From: Richard Todd <rwtodd@mac.com>
Cc: guile-devel@gnu.org
Subject: Re: building cvs guile on Mac OS X 10.4
Date: Sat, 14 May 2005 11:32:18 -0500 [thread overview]
Message-ID: <57919A66-6330-4DF7-94B3-E8BB2AE0F49B@mac.com> (raw)
In-Reply-To: <4285F804.2020407@ossau.uklinux.net>
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
next prev parent reply other threads:[~2005-05-14 16:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-08 7:36 building cvs guile on Mac OS X 10.4 Richard Todd
2005-05-12 6:39 ` Neil Jerram
2005-05-12 23:51 ` Richard Todd
2005-05-13 1:48 ` Kevin Ryde
2005-05-13 6:55 ` Neil Jerram
2005-05-14 12:49 ` Neil Jerram
2005-05-14 13:07 ` Neil Jerram
2005-05-14 16:32 ` Richard Todd [this message]
2005-05-15 23:31 ` Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57919A66-6330-4DF7-94B3-E8BB2AE0F49B@mac.com \
--to=rwtodd@mac.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).