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

[Bruce Korb]

On 12/20/10 11:20, Ralf Wildenhues wrote:
> * 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.
> 
> 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.

Hi Ralf,

As the person more intimately involved in the autotools as a whole
than about anybody else I know of, I was hoping you'd chime in.
(Maybe, too, someone who wrote a book on autotools.... ;)

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.

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

Regards, Bruce