[LLVMdev] configure with clang vs gcc

[reed kotler]

Almost done....

make[2]: Entering directory 
`/home/rkotler/caviumllvmwclang/build/projects/sample'
/home/rkotler/caviumllvmwclang/build/projects/sample/Makefile.llvm.config:50: 
*** Projects must define PROJ_INSTALL_ROOT.  Stop.
make[2]: Leaving directory 
`/home/rkotler/caviumllvmwclang/build/projects/sample'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/projects'


I don't know why configure is making so many mistakes here but i will 
examine that later.
It used to work for us.

On 02/25/2014 04:18 PM, Eric Christopher wrote:
> David Chisnall told you the most likely answer.
>
> -eric
>
> On Tue, Feb 25, 2014 at 4:07 PM, Reed Kotler <rkotler at mips.com> wrote:
>> looks like i need to --disable-terminfo
>>
>> i will have ot investigate in the end why configure gets the wrong answer
>> when using clang.
>>
>>
>> On 02/25/2014 03:21 PM, reed kotler wrote:
>>> I see what my problem is here....
>>>
>>> I'll continue to move further.
>>>
>>> Seems like Richards fix is still okay.
>>>
>>> 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
>>>>>>>>