[LLVMdev] Failure building llvm/clang from source using binary clang package on Mageia 2

Edward Diener
2013-01-14T01:32:41Z

On 01/12/2013 06:08 PM, Dmitri Gribenko wrote:
> On Sun, Jan 13, 2013 at 12:59 AM, Edward Diener
> <eldlistmailingz at tropicsoft.com>  wrote:
>> On 01/09/2013 10:37 AM, Dmitri Gribenko wrote:
>>>
>>> On Tue, Jan 8, 2013 at 8:43 AM, Edward Diener
>>> <eldlistmailingz at tropicsoft.com>   wrote:
>>>>
>>>> After applying your patch on Mageia 2 and invoking llvm's
configure:
>>>>
>>>> Using clang 3.0 I get:
>>>>
>>>> "checking whether clang works... no
>>>> configure: error: Selected compiler could not find or parse C++
standard
>>>> library headers.  Rerun with CC=c-compiler CXX=c++-compiler
./configure
>>>> ..."
>>>>
>>>> Using gcc, there is no error.
>>>>
>>>> After applying your patch on Fedora 17 and invoking llvm's
configure:
>>>>
>>>> Using clang 3.0 I get:
>>>>
>>>> "checking whether clang works... no
>>>> configure: error: Selected compiler could not find or parse C++
standard
>>>> library headers.  Rerun with CC=c-compiler CXX=c++-compiler
./configure
>>>> ..."
>>>>
>>>> Using gcc, there is no error.
>>>>
>>>> After applying your patch on Suse 12.2 and invoking llvm's
configure:
>>>>
>>>> Using clang 3.1, which has previously worked, there is no
error.
>>>>
>>>> So it looks to me, based on my tests, that your patch is
successful. I
>>>> look
>>>> forward to this update in llvm on subversion.
>>>
>>>
>>> I've committed a slightly different variant of this patch
r171975.
>>>
>>> Thank you for testing!
>>
>>
>> Unfortunately, after an attempt to use the latest 'configure'
update on
>> CentOS 6.3 I think your version may be slightly flawed.
>>
>> I had been able to build clang from source on CentOS 6.3 using clang
2.8-14
>> that is distributed as a binary. After your update, however, when I run
>> llvm/configure I receive:
>>
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables...
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether clang accepts -g... yes
>> checking for clang option to accept ISO C89... none needed
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether clang++ accepts -g... yes
>> checking how to run the C preprocessor... clang -E
>>
>> checking whether clang works... no
>> configure: error: Selected compiler could not find or parse C++
standard
>> library headers.  Rerun with CC=c-compiler CXX=c++-compiler ./configure
...
>>
>> When I run 'clang -v -fsyntax-only -x c++ /dev/null' I get:
>>
>> "clang version 2.8 (branches/release_28)
>> Target: x86_64-redhat-linux-gnu
>> Thread model: posix
>>   "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu
-fsyntax-only
>> -disable-free -disable-llvm-verifier -main-file-name null
-mrelocation-model
>> static -mdisable-fp-elim -mconstructor-aliases -munwind-tables
-target-cpu
>> x86-64 -target-linker-version 2.20.51.0.2 -v -resource-dir
>> /usr/lib/clang/2.8 -ferror-limit 19 -fmessage-length 144 -fexceptions
>> -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -x c++
/dev/null
>> clang -cc1 version 2.8 based upon llvm 2.8 hosted on
x86_64-redhat-linux-gnu
>>
>> #include "..." search starts here:
>> #include<...>  search starts here:
>>   /usr/include/c++/4.4.4
>>   /usr/include/c++/4.4.4/x86_64-redhat-linux
>>   /usr/include/c++/4.4.4/backward
>>   /usr/local/include
>>   /usr/lib/clang/2.8/include
>>   /usr/include
>>   /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
>> End of search list."
>>
>> It looks to me that clang 2.8-14 does indeed find the necessary header
>> files. Yet you are rejecting it. Also it did build clang successfully
before
>> your update.
>
> Can you pastebin the config.log file, please?  (I think that clang 2.8
> did not support __has_include that I used in the test, but I need the
> log file to check that it indeed caused the problem.)

It is on pastebin and is called ConfigureLog. I made it private, FWIW.