From: Noah Lavine <noah.b.lavine@gmail.com>
To: Bruce Korb <bruce.korb@gmail.com>
Cc: Libtool List <libtool@gnu.org>,
guile-devel@gnu.org, "Nelson H. F. Beebe" <beebe@math.utah.edu>
Subject: Re: How does one specify linking to 64 bit libraries when there is a choice?
Date: Sun, 19 Dec 2010 23:40:01 -0500 [thread overview]
Message-ID: <AANLkTimZO4034i_ydP9in=89sBKX+Htq+EWFJdPmadS1@mail.gmail.com> (raw)
In-Reply-To: <4D0BC3CD.2030103@gmail.com>
Hello,
I am not at all an expert on guile-config, but I will help if I can.
First of all, as to how guile-config works. At least in the latest git
version, it seems to be a thin wrapper for pkg-config.
I found the file that pkg-config will be using to give you this
information. It is meta/guile-<version number>.pc in my Guile source
tree. Furthermore, I think it's safe to assume that it is generated
from meta/guile-<version number>.pc.in.
But that file is just a pretty innocuous-looking template where it
looks like you paste some variables that would be generated by the
configure script.
Therefore, I have this question for you - are you able to configure
Guile to use 64-bit libs using the configure script?
Noah Lavine
On Fri, Dec 17, 2010 at 3:10 PM, Bruce Korb <bruce.korb@gmail.com> wrote:
> Hi Nelson,
>
> I am nearly certain we (you) have reached a point where
> libtool folks are going to say, "it is Guile", and Guile
> folks are going to say, "it is libtool". I am going to
> say, "I'd like some help from either or both".
>
> Because the guile-config invokes the guile binary in order
> to print out the unvarying strings from the configuration,
> it requires reverse engineering the entire Guile package
> to fully understand how it comes up with the strings it
> does. I can do it, but I am not any more eager than you.
>
> I think first up, someone from Guile needs to analyze
> the machinery behind "guile-config". I am willing to
> help with test runs on the utah.edu machines in order
> to diagnose the issue.
>
> Cheers - Bruce
>
> On 12/17/10 11:57, Nelson H. F. Beebe wrote:
>> Well, I have now done three more builds of guile-1.8.8. The first and
>> second supplied libdir=/usr/local/lib64 on the command line of all
>> "make" runs. That did not help: /usr/local/bin/guile-config still
>> reported -L/usr/local/lib.
>>
>> I found that LTLIBICONV still has -L/usr/local/lib in the first
>> attempt, so I replaced it by LTLIBICONV=-liconv for the second
>> attempt.
>>
>> For the third, I did "make clean", then used sed -i + xargs to
>> explicitly set libdir in every Makefile, in case it is not being
>> passed correctly to child makes.
>>
>> That too does not help:
>>
>> % /usr/local/bin/guile-config link | fmt -w 10
>> -pthread
>> -L/usr/local/lib
>> -lguile
>> -lltdl
>> -L/usr/local/lib64
>> -Wl,-rpath,/usr/local/lib64
>> -lgmp
>> -lcrypt
>> -lm
>> -lltdl
>>
>> For the fourth try, I used sed + xargs again to force all references
>> to the iconv library to just use a bare -liconv. Sadly, the incorrect
>> -L/usr/local/lib option still appears.
>>
>> % guile
>> guile> (define (get-build-info name)
>> (let ((val (assq name %guile-build-info)))
>> (if (not (pair? val))
>> (begin
>> (display-line-error
>> program-name " " subcommand-name ": no such build-info: " name)
>> (quit 2)))
>> (cdr val)))
>> guile> (get-build-info 'LIBS)
>> "-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64 -lgmp -lcrypt -lm -lltdl "
>> guile> (get-build-info 'libdir)
>> "/usr/local/lib"
>>
>> I'm unsure of where to proceed at this point. The logs of the four
>> tries are in
>>
>> /usr/local/gnu/src/guile/logs/guile-1.8.8/Typescript.abajo.math.utah.edu.2010.12.17.12.12.44.xz
>>
>> P.S. I leave the country on a 3-week trip next Saturday (25-Dec-2010),
>> and I won't have computer access during that time.
>
> That will be after I leave (22-Dec), but I get back 12/27
> (400 miles is still within the US). I would hope this is
> resolved before next Wednesday.......Have a nice trip & holiday!
> Regards, Bruce
>
>
next prev parent reply other threads:[~2010-12-20 4:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CMM.0.95.0.1292615864.beebe@psi.math.utah.edu>
2010-12-17 20:10 ` How does one specify linking to 64 bit libraries when there is a choice? Bruce Korb
2010-12-20 4:40 ` Noah Lavine [this message]
2010-12-20 10:56 ` Andy Wingo
2010-12-20 14:09 ` Bruce Korb
2010-12-20 14:23 ` Andy Wingo
2010-12-20 14:30 ` Ralf Corsepius
2010-12-20 19:20 ` Ralf Wildenhues
2010-12-20 19:25 ` Ralf Wildenhues
[not found] <AANLkTik3wAm4j4mqigf3-j0Kb=3HJ3OY-_sfhsiu3k-f@mail.gmail.com>
[not found] ` <CMM.0.95.0.1292605766.beebe@psi.math.utah.edu>
2010-12-17 17:31 ` Bruce Korb
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='AANLkTimZO4034i_ydP9in=89sBKX+Htq+EWFJdPmadS1@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=beebe@math.utah.edu \
--cc=bruce.korb@gmail.com \
--cc=guile-devel@gnu.org \
--cc=libtool@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).