Discussion:
havelib improvements
(too old to reply)
Bruno Haible
2017-02-19 18:47:28 UTC
Permalink
Raw Message
Hi,

In many installations, clang has strange/odd/buggy library search paths. In
particular, on the Ubuntu binaries from http://releases.llvm.org/download.html
search in /lib64/ although this directory contains no libraries (only the ld.so).
This confuses the AC_LIB_PREPARE_MULTILIB macro: it expects 64-bit libraries
in $PREFIX/lib64 (this hack was implemented for the sake of openSUSE systems).
But in Ubuntu, 64-bit binaries are in $PREFIX/lib.

I'm adding two patches:

1) The ability for the user to override the results of AC_LIB_PREPARE_MULTILIB.
With this patch, I can run the configuration with
acl_cv_libdirstems=lib,lib64 CC=clang ./configure --with-libsigsegv-prefix=...
and it (i.e. gl_LIBSIGSEGV) will find the installed 64-bit binaries of
libsigsegv, whereas before with just
CC=clang ./configure --with-libsigsegv-prefix=...
it did not find them.

2) Prefer to ask the system compiler (/usr/bin/gcc) about the characteristics of
the system, rather than $CC.
Pádraig Brady
2017-02-20 01:31:39 UTC
Permalink
Raw Message
Post by Bruno Haible
Hi,
In many installations, clang has strange/odd/buggy library search paths. In
particular, on the Ubuntu binaries from http://releases.llvm.org/download.html
search in /lib64/ although this directory contains no libraries (only the ld.so).
This confuses the AC_LIB_PREPARE_MULTILIB macro: it expects 64-bit libraries
in $PREFIX/lib64 (this hack was implemented for the sake of openSUSE systems).
But in Ubuntu, 64-bit binaries are in $PREFIX/lib.
1) The ability for the user to override the results of AC_LIB_PREPARE_MULTILIB.
With this patch, I can run the configuration with
acl_cv_libdirstems=lib,lib64 CC=clang ./configure --with-libsigsegv-prefix=...
and it (i.e. gl_LIBSIGSEGV) will find the installed 64-bit binaries of
libsigsegv, whereas before with just
CC=clang ./configure --with-libsigsegv-prefix=...
it did not find them.
2) Prefer to ask the system compiler (/usr/bin/gcc) about the characteristics of
the system, rather than $CC.
Thanks for fixing that.

I've also seen clang auto include stuff that it really shouldn't.
For example if a Red Hat developer toolset is installed,
that can be enabled using the standard software collections mechanism
on RHEL and Centos. The main point being is that the standard
system installs are unaffected, and enablement is explicit.
However clang will _auto enable_ the latest found, which causes
hard to diagnose issues. Some info at: https://bugzilla.redhat.com/1139077
Loading...