[klee-dev] using klee without llvm-gcc?

[Hongxu Chen]

Thanks for your reply, Dan.
I followed your advice using clang2.9 to build bca files and build llvm,stp
successfully; but UCLIBC fails. 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?

The build command and the log files is also attached.

Thanks,
Hongxu Chen


On Sun, Mar 17, 2013 at 10:18 PM, Daniel Liew
<daniel.liew at imperial.ac.uk> wrote:
>
> On 17 March 2013 03:20, Hongxu Chen <leftcopy.chx at gmail.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3-uclibc.sh
Type: application/x-sh
Size: 349 bytes
Desc: not available
URL: <http://mailman.ic.ac.uk/pipermail/klee-dev/attachments/20130318/e5efacf7/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log-1-llvm
Type: application/octet-stream
Size: 131132 bytes
Desc: not available
URL: <http://mailman.ic.ac.uk/pipermail/klee-dev/attachments/20130318/e5efacf7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log-3-uclibc
Type: application/octet-stream
Size: 1711 bytes
Desc: not available
URL: <http://mailman.ic.ac.uk/pipermail/klee-dev/attachments/20130318/e5efacf7/attachment-0001.obj>