Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ralf Wildenhues]

* Bruce Korb wrote on Mon, Dec 20, 2010 at 09:37:58PM CET:
> On 12/20/10 11:20, Ralf Wildenhues wrote:
> > 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.
> > 
> > At least with current Libtool you can override wrong settings with the
> > lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
> > cache variables.

> Addressing things in reverse order:
> 
> 1. "lt_cv_sys_lib..." It is true that authors of packages need to be
>    more knowledgeable than the "hapless builder", still they should
>    not have to fiddle with undocumented internals; and cached variable
>    values seem like grody internals to me.

I fully agree that such knowledge /should/ not be required.  It's a bug
that libtool doesn't get the right setting by default.

> 2. Waaaaay back at the beginning, with a default installation of
>    RHEL for amd-64/x86-64, these commands fail:
> 
>    $ cd $guile_build_dir
>    $ $guile_src/configure && make && sudo make install
>    $ cd $autogen_build_dir
>    $ $autogen_src/configure && make && sudo make install
> 
>    and it fails because `guile-config link` produces output
>    that libtool interprets and then passes, as a full path name,
>    a library listed as ``-lXXX'' in the guile-config
>    output.  The full path, of course, is to a 32 bit shared obj
>    in  a 64 bit link command.  Oops.
> 
>    So this means that if "ld" could have identified a 32 bit shared obj
>    and gone on to look in another directory, all would have been well.
>    Instead, "ld" saw a full path and tried to do what it was told,
>    but said, "no, I won't do that".
> 
> 3. CF:
> > 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),
>   So DO NOT REPLACE ``-lgmp'' with ``/usr/local/lib/libgmp.so''!!!
>   libtool did this and triggered the whole thread.

Again: the replacement of -lgmp with /usr/local/lib/libgmp.so might be
the thing that makes the failure visible, but it is not the underlying
cause, and trying to avoid the replacement is like trying to make
someone go away by closing your eyes.  The error happened earlier: at
the time /usr/local/lib was introduced into the libtool search path.

The replacement of -lfoo with /abs/path/to/libfoo.so on some systems,
notably GNU/Linux, is very helpful in being able to reliably link
against uninstalled libraries even in the presence of -L/some/inst/path
early on the link command line.  Crying against this will not fix the
issue (as there are other places where libtool will get things wrong for
you even if you inhibit this, once it looks in the wrong directories).

>   See: http://lists.gnu.org/archive/html/libtool/2010-12/msg00041.html
> 
> Just a note: if a distro puts 64 bit SOs in /usr/lib64, then it is
> reasonable to put add-on 64 bit SOs into /usr/local/lib64.  In fact,
> I would consider it peculiar to put 'em into /usr/local/lib.

Sure, that's what you would expect.  What can libtool expect though?
I don't think /usr/local can be treated as necessarily having the same
policy as /usr has, one coming from the distro and the other containing
all kinds of non-adapted (even non-GNU standards using) junk.

> The difference should just be $prefix (i.e. "/usr" vs. "/usr/local").
> If my sloppiness regarding distinguishing /usr/lib from /usr/local/lib
> caused any confusion, my apologies.  The final lib directory name
> should be consistent.

I fail to see how it would be possible to ingrain this rule into all of
our users, overnight.

Cheers,
Ralf