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