unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Bruce Korb <bkorb@gnu.org>
Cc: Bruce Korb <bruce.korb@gmail.com>, Libtool List <libtool@gnu.org>,
	"Nelson H. F. Beebe" <beebe@math.utah.edu>,
	guile-devel@gnu.org
Subject: Re: How does one specify linking to 64 bit libraries when there is a choice?
Date: Mon, 20 Dec 2010 20:20:25 +0100	[thread overview]
Message-ID: <20101220192025.GB22777@gmx.de> (raw)
In-Reply-To: <4D0F63AC.2080303@gnu.org>

* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
>   How much understanding of the machinery should be expected
>   of the hapless project builder?

I've skimmed most of the conversation in this thread now.

The crucial part, I think, is *not* the --libdir setting.  Distros
usually get that consistent between their packages, and users should not
be using any of /usr/lib{,32,64} but rather something below /usr/local.

One crucial part is that libtool gets confused whenever it has
directories with the wrong ABI in the search path (unlike ld or ld.so,
both are in some cases smart enough to skip wrong ABI), which means that
either no instance of the build system machineries may introduce such
paths, or libtool needs to get smarter to ignore wrong ABI dirs.

The other crucial part is that libtool doesn't get the
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
right on several distros, introducing such wrong directories itself (not
to speak of cross setups).  There have been several proposed patches to
address this, e.g.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
but I have yet to see one that solves it.

Thanks,
Ralf



  parent reply	other threads:[~2010-12-20 19:20 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
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 [this message]
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=20101220192025.GB22777@gmx.de \
    --to=ralf.wildenhues@gmx.de \
    --cc=beebe@math.utah.edu \
    --cc=bkorb@gnu.org \
    --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).