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