[LLVMdev] configure with clang vs gcc

[Reed Kotler]

COmplete build now successful.

Yay!

I will try and figure out what is wrong with configure as a background task.

But I have a way to build the mips hosted version using clang/llvm 
instead of gcc.

Now to debug this compiler.

Reed

On 02/25/2014 04:01 PM, reed kotler wrote:
> I'm getting much further now.
>
> The next problem is libtinfo
>
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory
> `/home/rkotler/caviumllvmwclang/build/lib/TableGen'
> make[1]: Entering directory `/home/rkotler/caviumllvmwclang/build/utils'
> make[2]: Entering directory
> `/home/rkotler/caviumllvmwclang/build/utils/FileCheck'
> llvm[2]: Linking Release+Asserts executable FileCheck (without symbols)
> /mips/arch/overflow/codesourcery/mips-linux-gnu/lite/release/2013.05-66/Linux/lib/gcc/mips-linux-gnu/4.7.3/../../../../mips-linux-gnu/bin/ld:
> cannot find -ltinfo
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[2]: ***
> [/home/rkotler/caviumllvmwclang/build/Release+Asserts/bin/FileCheck]
> Error 1
> make[2]: Leaving directory
> `/home/rkotler/caviumllvmwclang/build/utils/FileCheck'
> make[1]: *** [FileCheck/.makeall] Error 2
> make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/utils'
> make: *** [all] Error 1
> rkotler at mipssw006:~/caviumllvmwclang/build$
>
> It's not in the gcc mips toolchain but for some reason when I configure
> with clang it is looking for it.
>
> On 02/25/2014 02:42 PM, Eric Christopher wrote:
>> On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote:
>>> On 02/25/2014 02:38 PM, Eric Christopher wrote:
>>>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:
>>>>> On 02/25/2014 09:30 AM, Richard Sandiford wrote:
>>>>>> reed kotler <rkotler at mips.com> writes:
>>>>>>> On 02/24/2014 04:42 PM, Eric Christopher wrote:
>>>>>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com>
>>>>>>>> wrote:
>>>>>>>>> I need to leave soon and will take a look in the morning.
>>>>>>>>>
>>>>>>>>> I did look at the autoconf input files configure.ac
>>>>>>>>>
>>>>>>>>> There is a disable-zlib but not a disable-valgrind, even though it
>>>>>>>>> seems
>>>>>>>>> like there used to be.
>>>>>>>>> You can find scripts on the internet when you google of people
>>>>>>>>> adding
>>>>>>>>> disable-valgrind to configure.
>>>>>>>>>
>>>>>>>>> I can probably implement disable-valgrind in configure.ac.
>>>>>>>> This isn't what I was asking. You can, of course, do that, but it's
>>>>>>>> orthogonal to the issue at hand. Basically my initial thought is
>>>>>>>> that
>>>>>>>> it's using the contents of the build host and not the host.
>>>>>>>>
>>>>>>>> -eric
>>>>>>> Right.
>>>>>>>
>>>>>>> There are two issues.
>>>>>>>
>>>>>>> 1 ) THere should be a way to disable valgrind as you can for zlib.
>>>>>> FWIW, because of inline asm in valgrind.h that LLVM can't yet
>>>>>> handle, I
>>>>>> use:
>>>>>>
>>>>>>      ac_cv_header_valgrind_valgrind_h=no .../configure ...
>>>>> when i do that i get:
>>>>>
>>>>> llvm[1]: Compiling regfree.c for Release+Asserts build
>>>>> llvm[1]: Compiling regstrlcpy.c for Release+Asserts build
>>>>> llvm[1]: Compiling system_error.cpp for Release+Asserts build
>>>>> llvm[1]: Building Release+Asserts Archive Library libLLVMSupport.a
>>>>> make[1]: ***
>>>>>
>>>>> [/home/rkotler/caviumllvmwclang/build/Release+Asserts/lib/libLLVMSupport.a]
>>>>>
>>>>> Error 127
>>>>> make[1]: Leaving directory
>>>>> `/home/rkotler/caviumllvmwclang/build/lib/Support'
>>>>> make: *** [all] Error 1
>>>>> rkotler at mipssw006:~/caviumllvmwclang/build$
>>>>>
>>>>>
>>>> Not enough context.
>>>
>>> That is what it printed out.
>>> I'm guessing that it still wanted to link in that module even though
>>> it knew
>>> no to compile it.
>>> I will debug this and figure out why configure is getting the wrong
>>> answers
>>> with clang.
>>>
>> You didn't paste where an error occurred. And Richard, David, and I
>> have all given you your likely problem.
>>
>> -eric
>>
>>>> -eric
>>>>
>>>>>> when bootstrapping clang on z.  Obviously --disable-valgrind would be
>>>>>> cleaner but this is another way out.
>>>>>>
>>>>>> (Of course, I agree with what Eric says about it finding the wrong
>>>>>> set
>>>>>> of headers.)
>>>>>>
>>>>>> Thanks,
>>>>>> Richard
>>>>>>