[LLVMdev] configure with clang vs gcc

[reed kotler]

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
>>>>>