[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

From: Neil Jerram
Subject: Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4
Date: Sat, 08 Mar 2008 12:19:59 +0000
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Hans Aberg <address@hidden> writes:

> On 7 Mar 2008, at 23:21, Neil Jerram wrote:
>>> Otherwise, a fix might be that the Guile installation checks for
>>> readline in /usr/local/.
>> I could well be wrong, but my current understanding is that that won't
>> work, because at link time GCC or ld.so
> (On Mac OS X, dynamic libraries end with .dylib, being a Mach-O
> format. The .so is for a fromat used on GNU/Linux computers.)

OK, thanks.

>> will always prefer to pick up
>> -lreadline from /usr/lib rather than from /usr/local/lib.
> It could be, because the reason I installed latest readline was that I
> wanted Hugs and GHCi working with UTF-8, and it didn't work.
> Suppose I set a soft link from the system readline to the newly
> installed, would it suffice to set it from
>   /usr/lib/libreadline.<ext> -> /usr/local/lib/libreadline.<ext>

Yes, that should work.  Sysadmin-wise, it's a confusing change to keep
track of, though.

> Or must some other stuff, like in /usr/include, also be relinked?

No, I don't think that will be needed.  As long as you have
CFLAGS=-I/usr/local/include when you run ./configure, I believe that
headers under /usr/local/include will be picked up in preference to
those under /usr/include.

(BTW, this is something that I've never seen a good explanation for.
-I/usr/local/include takes preference over the standard /usr/include,
but -L/usr/local/lib doesn't take preference over the standard
/usr/lib.  What is the logic there?)


reply via email to

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