<div dir="ltr">The reason this was added in the first place was that certain builds (android?  I think) would break when libxml was present but iconv was not.  Libxml2 uses iconv for some internationalization encoding it does (<a href="http://xmlsoft.org/encoding.html" target="_blank">http://xmlsoft.org/encoding.<wbr>html</a>).  Even though libxml2 was found on these builds, a compile time error which went something like “fatal error: iconv.h: No such file or directory" would be thrown.  This is perhaps a bug with libxml2 in that it assumes iconv is present in all situations.<div><br></div><div>I'm not sure why the check was made specific to Linux, perhaps check with Nico, this was done in r315873.</div><div><br></div><div>Sorry this was a while ago and this is most of the info I can give.<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 2:18 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've reverted this in r317517 as it (silently) broke our builds, i.e.<br>
it was no longer setting LLVM_LIBXML2_ENABLED.<br>
<br>
Questions inline.<br>
<span class=""><br>
On Tue, Oct 17, 2017 at 11:26 PM, Serguei Katkov via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Author: skatkov<br>
> Date: Tue Oct 17 23:26:39 2017<br>
> New Revision: 316064<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=316064&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=316064&view=rev</a><br>
> Log:<br>
> Fix the incorrect detection of ICONV_LIBRARY_PATH<br>
><br>
> This is introduced in rL308711.<br>
> Check for c library is incorrect here just because libc will be found always<br>
> and it does not mean that iconv is presented.<br>
><br>
> Thank to Andrew Krasny for narrowing down the root cause.<br>
<br>
</span>What this was the root cause of? I couldn't find any bug, and no<br>
discussion on the code review or mailing list.<br>
<span class=""><br>
> Reviewers: ecbeckmann<br>
> Reviewed By: ecbeckmann<br>
> Subscribers: mgorny, llvm-commits<br>
> Differential Revision: <a href="https://reviews.llvm.org/D38875" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D38875</a><br>
><br>
> Modified:<br>
>     llvm/trunk/cmake/config-ix.<wbr>cmake<br>
><br>
> Modified: llvm/trunk/cmake/config-ix.<wbr>cmake<br>
> URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/config-ix.cmake?rev=316064&r1=316063&r2=316064&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/llvm/trunk/cmake/<wbr>config-ix.cmake?rev=316064&r1=<wbr>316063&r2=316064&view=diff</a><br>
> ==============================<wbr>==============================<wbr>==================<br>
> --- llvm/trunk/cmake/config-ix.<wbr>cmake (original)<br>
> +++ llvm/trunk/cmake/config-ix.<wbr>cmake Tue Oct 17 23:26:39 2017<br>
> @@ -157,7 +157,7 @@ if( NOT PURE_WINDOWS AND NOT LLVM_USE_SA<br>
>      set(HAVE_TERMINFO 0)<br>
>    endif()<br>
><br>
> -  find_library(ICONV_LIBRARY_<wbr>PATH NAMES iconv libiconv libiconv-2 c)<br>
> +  find_library(ICONV_LIBRARY_<wbr>PATH NAMES iconv libiconv libiconv-2)<br>
<br>
</span>On Linux, I believe libc usually provides iconv() which is why the<br>
check was written that way.<br>
<span class=""><br>
>    set(LLVM_LIBXML2_ENABLED 0)<br>
>    set(LIBXML2_FOUND 0)<br>
>    if((LLVM_ENABLE_LIBXML2) AND ((CMAKE_SYSTEM_NAME MATCHES "Linux") AND (ICONV_LIBRARY_PATH) OR APPLE))<br>
<br>
</span>But this raises lots of questions.<br>
<br>
Why do we need to check for iconv here? Isn't it enough that we find<br>
libxml2; i.e., if we find it, can't we assume that it's usable?<br>
<br>
And why is the iconv() check specific to Linux? Is it not needed on<br>
Mac, and what if the user is on FreeBSD or something else -- no<br>
libxml2 for them?<br>
<br>
Does anyone know what's going on here?<br>
<br>
Thanks,<br>
Hans<br>
</blockquote></div><br></div>