Looks much better. The stdc library things are caused by Cygwin's inability to recognize symbols linked into the main program with dlsym. For example, if lli (the interpreter) has "printf" already linked in, then the JIT compiler will not be able to find "printf" if it is used in the program it is compiling. There's currently no workaround for this other than to fix Cygwin. Not sure about the other errors. In general, this should be good enough for you to do most things. Reid. On Fri, 2005-05-20 at 19:45 +0100, Aaron Gray wrote:> Much better. Although it looks like I have a library problem though. > > There are by the look of it a few more errors too. > > # of expected passes 1736 > # of unexpected failures 16 > # of expected failures 56 > > Looks like the patch has nearly got it. > > Aaron > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050520/8fe93e1b/attachment.sig>
Reid,>Looks much better. The stdc library things are caused by Cygwin's >inability to recognize symbols linked into the main program with dlsym. >For example, if lli (the interpreter) has "printf" already linked in, >then the JIT compiler will not be able to find "printf" if it is used in >the program it is compiling. There's currently no workaround for this >other than to fix Cygwin. Not sure about the other errors. In general, >this should be good enough for you to do most things.Great. Thanks alot for all your support. I hope it has been useful exercise for llvm as well as getting me started with a development environment. Next is the llvm-test set. But I will leave that till next week :) I am wondering whether it is worth me preparing a html document describing the whole process from updating GCC and LD to LLVM to the CFE and make check for others to follow. The other thing is making a Cygwin Binary availiable. I could do both these things and put them on the web. The only thing I am concerned about is a long development cycle, do I have to do a 'make' or 'make tools-only' followed by a 'make install' and a 'make check' every time I want to test some change ? I can do most of the development in MS Visual Studio which will allow a much faster build. But will need to use Cygwin for the test cycles. I am hopefully going to get the NASM backend written now, followed by a COFF and possibly direct Windows PE backends. Cheers, Aaron
On Fri, May 20, 2005 at 09:54:06PM +0100, Aaron Gray wrote:> I am wondering whether it is worth me preparing a html document > describing the whole process from updating GCC and LD to LLVM to the > CFE and make check for others to follow.This would be a very useful addition to our documentation.> The other thing is making a Cygwin Binary availiable. I could do both > these things and put them on the web.This would be appreciated as well. If you post it somewhere, we can add it to the 'contrib' section of our download page for version 1.5 .> The only thing I am concerned about is a long development cycle, do I > have to do a 'make' or 'make tools-only' followed by a 'make install' > and a 'make check' every time I want to test some change ?Most of us who recompile LLVM often add the directory $objdir/Debug/bin to our path and just use those tools directly. This lets you skip "make install", but you still have to run "make" all the time to recompile your tools. If you want to speed up your build, you can edit tools/Makefile and delete all the tools that you don't use. It's still a good idea to make a full build every now and then to make sure you didn't break anything globally. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu