Hi, Daniel and David, it's very kind of you to share so many details, thanks very much.
Firstly I would say that I made a mistake, STP was still built with gcc/g++; sorry about that. The source package of uclibc hasn't been corrupted since it was newly downloaded, also I always `make clean' before a new build. I actually built uclibc successfully in one of my virtual machines several days ago, and today I took the $(LLVMROOTDIR)/Makefile.config, but still the same error message. Also when uclibc is configured with `--with-gcc' option, the output in the old virtual machine is different from the one I am currently on(although the gcc version is the same). So I suppose that there may be some errors with my system environments, but I haven't figured out it. At present, I just use the pre-compiled uclibc; although klee always complains that data layout is different, it at least works. Thanks for your help! Regards, Hongxu Chen On Tue, Mar 19, 2013 at 7:48 PM, Daniel Liew <[email protected]>wrote: > On 18 March 2013 15:43, Hongxu Chen <[email protected]> wrote: > > Thanks for your reply, Dan. > > I followed your advice using clang2.9 to build bca files and build > llvm,stp > > successfully; but UCLIBC fails. > Just to say there isn't a requirement to build STP with a LLVM > compiler but the fact that it did compile is good news :) > > klee has partially been built and libs like > > libkleeRuntimeIntrinsic.bca,libkleeRuntimePOSIX.bca and libklee-libc.bca > has > > already came out. For uclibc, the error message is a bit confusing: > > > > In file included from libcrypt/crypt.c:11: > > libcrypt/libcrypt.h:11:78: error: expected function body after > > function declarator > > extern char *__md5_crypt(const unsigned char *pw, const unsigned > > char *salt) attribute_hidden; > > > > ^ > > libcrypt/libcrypt.h:12:78: error: expected function body after > > function declarator > > extern char *__des_crypt(const unsigned char *pw, const unsigned > > char *salt) attribute_hidden; > > > > ^ > > libcrypt/crypt.c:18:10: warning: implicit declaration of function > > '__md5_crypt' is invalid in C99 [-Wimplicit-function-declaration] > > return __md5_crypt((unsigned char*)key, (unsigned > > char*)salt); > > ^ > > libcrypt/crypt.c:18:10: warning: incompatible integer to pointer > > conversion returning 'int' from a function with result type 'char *' > > return __md5_crypt((unsigned char*)key, (unsigned > > char*)salt); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > libcrypt/crypt.c:20:10: warning: implicit declaration of function > > '__des_crypt' is invalid in C99 [-Wimplicit-function-declaration] > > return __des_crypt((unsigned char*)key, (unsigned > > char*)salt); > > ^ > > libcrypt/crypt.c:20:10: warning: incompatible integer to pointer > > conversion returning 'int' from a function with result type 'char *' > > return __des_crypt((unsigned char*)key, (unsigned > > char*)salt); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 4 warnings and 2 errors generated. > > make: *** [libcrypt/crypt.os] Error 1 > > > > Here in Rules.mak.llvm, `LLVMGCC' has been changed to > $(LLVMTOOLDIR)/clang. > > Similar error occurred when I set LLVMGCC to a pre-compiled llvm-gcc(from > > llvm2.9 download > > page,http://llvm.org/releases/2.9/llvm-gcc4.2-2.9-x86_64-linux.tar.bz2). > > > > make: *** [libcrypt/crypt.os] Error 1 > > In file included from libcrypt/crypt.c:11: > > libcrypt/libcrypt.h: In function '__md5_crypt': > > libcrypt/libcrypt.h:11: error: expected declaration specifiers > > before 'attribute_hidden' > > libcrypt/libcrypt.h:12: error: expected '=', ',', ';', 'asm' or > > '__attribute__' before 'attribute_hidden' > > libcrypt/crypt.c:14: error: expected '=', ',', ';', 'asm' or > > '__attribute__' before '{' token > > libcrypt/crypt.c:21: error: expected '{' at end of input > > make: *** [libcrypt/crypt.os] Error 1 > > > > I also tried the `--with-gcc' option when configuring(AFAIK, CC is set > to gcc), > > and the error message is exactly the same as llvm-gcc case. > > > > 1. So has anyone else ever built > > klee-uclibc-0.02-x64/klee-uclibc-0.02-i386 with > > native gcc and met similar problems? > > 2. The `Rules.mak.llvm' actually reads > > `$(LLVMROOTDIR)//Makefile.config`, so maybe > > I again made some mistakes when building llvm? > > Something very odd is happening there you shouldn't be getting parse > errors. I have never seen that problem. I can only really suggest > three things things > - It's very unlikely but check your source code for uclibc hasn't been > corrupted > - run `make VERBOSE=1` and check the command being used to build > crypt.os is correct. > - I'm not really 100% sure why $(LLVMROOTDIR)/Makefile.config is being > included but I managed to build without it being included in the > makefile. You could try removing it then doing `make clean && make` > > For your reference this is the command that is executed on my system > (I've shortened the llvm-gcc path) to build crypt.os > > llvm-gcc --emit-llvm -c ../libcrypt/crypt.c -o ../libcrypt/crypt.os > -include ../include/libc-symbols.h -Wall -Wstrict-prototypes > -fno-strict-aliasing -fno-stack-protector -fno-builtin -nostdinc > -I../include -I. -DSTATIC -std=gnu99 -O0 -g3 -I/usr/include/ -isystem > > /data/dev/KLEE/llvm-gcc/bin/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include > -DNDEBUG -fPIC -DNOT_IN_libc -DIS_IN_libcrypt > > Out of curiosity I did have a quick try at compiling > klee-uclibc-0.02-x64 using clang (version 3.1 because that's what is > on my system and llvm tools 3.1). I really do not advise it as I had > to blindly change some of the code to make it compile and I'm not sure > what the consequences are. > > I hacked the Rules.mak file with.. > > LLVMGCC := clang > CC = $(LLVMGCC) -emit-llvm > AR = llvm-ar-3.0 > LD = llvm-ld-3.0 > NM = llvm-nm-3.0 > > The configure script included with klee-ucblic-0.02 is just a hack so > I didn't bother running it. I had to hack libc/misc/sysvipc/ipc.h > header so that the defines were set (removed #ifdef __NR_ipc and > associated #endif) and then I could run `make`. > > > Regards, > Dan Liew. > > > > > Thanks, > > Hongxu Chen > > > > > > On Sun, Mar 17, 2013 at 10:18 PM, Daniel Liew > > <[email protected]> wrote: > >> > >> On 17 March 2013 03:20, Hongxu Chen <[email protected]> wrote: > >> > Dear all, > >> > > >> > It seems that > >> > llvm-gcc-4.2-2.9( > http://llvm.org/releases/2.9/llvm-gcc-4.2-2.9.source.tgz) > >> > suggested by the getting started page of klee has many problems and is > >> > treated as obsolete by the llvm community. For me, an internal error > >> > occurred when I built it with an debug version of llvm-2.9. So I have > some > >> > questions about klee: > >> > >> It is indeed the case that llvm-gcc is obsolete. I found this when I > >> first started working on KLEE but I ignored the issue as I needed to > >> work with something that was stable. > >> > >> > Is it possible to build llvm without llvm-gcc when I have to use klee > and > >> > uclibc? This page(http://klee.llvm.org/GetStarted.html) says that > llvm-gcc > >> > has to be added into $PATH so that llvm would choose llvm-gcc other > than gcc > >> > or clang to build llvm. The key difference is that llvm-gcc generates > >> > libkleeRuntimeIntrinsic.bca(and the related posix,uclibc runtime .bca > >> > library; this thread tells the details ). I took a glance at the > configure > >> > file of llvm but didn't figure out how it is done. So I am wondering > whether > >> > clang-compiled llvm also has libkleeRuntimeIntrinsic.bca and the > like. I > >> > came across another project called klee-fp, which uses clang and > llvm-3.0; > >> > additionally they also use uclibc, But there is a compilation error > when I > >> > built klee-fp(actually the error is in the compilation of stp, which > is > >> > inside klee-fp source code folder). > >> > If those .bca files can only be generated by llvm-gcc, then is there > any > >> > trick when I use llvm-gcc > >> > binary( > http://llvm.org/releases/2.9/llvm-gcc4.2-2.9-x86_64-linux.tar.bz2) > >> > (instead of building llvm-gcc from souce) to compile llvm? There are > still > >> > some compilation errors for me. > >> > >> I tried compiling llvm-gcc from source about a year ago I couldn't get > >> anywhere with it so I just used the llvm-gcc binaries and KLEE will > >> build fine. There is nothing really stopping you as far as I know from > >> using clang instead of llvm-gcc to build libkleeRuntimeIntrinsic.bca > >> and other KLEE bitcode libraries. You should use a version of clang > >> though that uses the same version of LLVM that you intend to use with > >> KLEE. KLEE relies on LLVM's build system so for things to work in KLEE > >> so a LLVM compiler (either llvm-gcc or clang) needs to be detected > >> (i.e. in PATH) when you configure llvm for building. > >> > >> This will probably cause you a little bit of hassle if you build llvm > >> and clang from scratch as you'll probably need to build llvm and clang > >> using gcc and then build llvm again using your newly built clang > >> compiler. > >> > >> If you use your distribution's version of clang and build llvm from > >> source so that it matches your clang version you will make life easier > >> for yourself. > >> > >> Having said that, I don't believe KLEE supports LLVM 3.1 properly (the > >> IR has changed since llvm 2.9) so expect some issues to appear if you > >> use clang. I'm also not sure if KLEE's testframe work will behave if > >> you use clang instead. > >> > >> KLEE being stuck using llvm-gcc and llvm 2.9 is definitely an issue > >> which we need to address at some point. It's something that personally > >> I'd like to address as well. > >> > >> Regards, > >> Dan Liew. >
_______________________________________________ klee-dev mailing list [email protected] https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
