unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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
>
>



  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).