[LLVMdev] configure with clang vs gcc

[Eric Christopher]

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.

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