From: Hans Aberg <haberg@math.su.se>
To: Neil Jerram <neil@ossau.uklinux.net>
Cc: bug-guile@gnu.org
Subject: Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4
Date: Sat, 8 Mar 2008 14:48:39 +0100 [thread overview]
Message-ID: <5DF13EDD-4370-4798-9611-6F92EC150B4C@math.su.se> (raw)
In-Reply-To: <87d4q5be6o.fsf@ossau.uklinux.net>
On 8 Mar 2008, at 13:19, Neil Jerram wrote:
>> (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.
For what I have checked, the functions are named the same. So if one
assumes the dynamic libraries have been created on Mac OS X, the only
change needed in the source code is to look for files ending
in .dylib instead of .so.
>>> 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.
Yes, it is a mess. :-)
>> 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?)
It is certainly causing problems. Somebody got problems on the GMP
list reported problems with that package and Guile (Mac OS X 10.5
Intel perhaps). But it strikes me now, in view of your letters, that
it might be due to the same issue as with readlib.
Do you happen to know with there are any environment variables one
might set for GCC, like LIBPATH, INCLUDEPATH, or something, that
ensures /usr/local is included? This would be a convenient method.
Hans Aberg
prev parent reply other threads:[~2008-03-08 13:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 18:03 Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4 Hans Aberg
2008-02-23 10:13 ` Ludovic Courtès
2008-02-23 18:21 ` Neil Jerram
2008-03-07 19:55 ` Neil Jerram
2008-03-07 21:20 ` Hans Aberg
2008-03-07 22:21 ` Neil Jerram
2008-03-07 23:13 ` Hans Aberg
2008-03-08 12:19 ` Neil Jerram
2008-03-08 13:48 ` Hans Aberg [this message]
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=5DF13EDD-4370-4798-9611-6F92EC150B4C@math.su.se \
--to=haberg@math.su.se \
--cc=bug-guile@gnu.org \
--cc=neil@ossau.uklinux.net \
/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).