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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
