bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: havelib improvements


From: Pádraig Brady
Subject: Re: havelib improvements
Date: Sun, 19 Feb 2017 17:31:39 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 19/02/17 10:47, Bruno Haible wrote:
> 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.
> 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]