similar to: [LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM

Well, Henrik has a point. As of now, the only thing LLVM is good for when built with VS is the JIT engine, and then only if you're willing to write your own front end--or be satisfied computing fibonacci numbers :) That doesn't make it useless, of course, as Morten will testify, but the market for this level of functionality can't be big. I do plan on creating projects to build llc

Hi, when building the llvm cfe (3.4 derivative), for the mingw platform, I get this error: 'error: there are no arguments to `lrand48' that depend on a template parameter, so a declaration of `lrand48' must be available'. ------------------------ make[3]: Entering directory `/C/projects/build/MinGW/llvm-gcc-1-1/i686-pc-mingw32/libstdc++-v3/testsuite'

Hi Here is my first patches to the Win32 platform. They compile on the mingw platform. I haven't test them yet, but I thought it will best to put them in the save, just in case... /Henrik _________________________________________________________________ F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ -------------- next part -------------- An embedded and

Hi, Today I've succeded in compiling the llvm-tools, llvm-gcc and stacker frontend and in installing it. Uptill now I've followed the steps given in: http://llvm.cs.uiuc.edu/docs/CFEBuildInstrs.html with modifications for the mingw platform. I'll return with step-by-step instructions how to do it on this platform. Cheers Henrik :)

> Yuck... what about the C runtime? I can compile a C/C++ program on Unix > and copy the bytecode file over to Windows and then (eventually) > generate assembler that NASM can turn into a binary. But what to link > against? Microsoft's C runtime library? C++ runtime is even worse, as > name mangling is completely different. Then there's __cdecl vs > __fastcall. VC++

This sounds suspiciously like the problem I ran into with VC++, whose std implementation also includes _Distance. Could mingw have copied VC++ too closely? The fix with VC++ was to add a "using std::_Distance" line (or just "using namespace std". Chris Lattner wrote: > On Fri, 14 Jan 2005, Henrik Bach wrote: > >> when building the llvm cfe (3.4 derivative), for

On Tue, 16 Nov 2004, Jeff Cohen wrote: > > Yuck... what about the C runtime? I can compile a C/C++ program on Unix > > and copy the bytecode file over to Windows and then (eventually) > > generate assembler that NASM can turn into a binary. But what to link > > against? Microsoft's C runtime library? C++ runtime is even worse, as > > name mangling is

Hi, I get this error: --------------- configure: configuring in projects/Stacker configure: running /bin/sh '/C/projects/src/llvm-2/llvm/projects/Stacker/configure' --prefix=/C/LLVM/tools/ '--prefix=/C/LLVM/tools/' 'CPPFLAGS=-D__MINGW -DLLVM_ON_WIN32=1' --cache-file=/dev/null --srcdir=/C/projects/src/llvm-2/llvm/projects/Stacker configure: error: invalid variable

This is one of the reasons I'm getting rid of the "platform" link. I'm not sure what platform you're working on, but on Cygwin it causes problems. Cygwin doesn't like .. through a soft link and generates incorrect file names. I imagine this is what is happening to the dependencies. In any event, the "platform" link will be gone before the new year. Sorry for

On Fri, 14 Jan 2005, Henrik Bach wrote: > when building the llvm cfe (3.4 derivative), for the mingw platform, I get > this error: 'error: there are no arguments to `lrand48' that depend on a > template parameter, so a declaration of `lrand48' must be available'. Hi Henrik, We haven't modified the GCC configure script or build system, so I don't know what

Hi Reid, Looking closer at the build process, I find that Path.cpp doesn't get compiled, even if it is a newer version than its *.o file. That's probaly the reason the error still exists. I've zipped and attached the trace after the point the new Path.cpp was updated by cvs. It clearly shows that it newer gets compiled and now shows that it is the dependencies in the makefile

============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ =============================================================

Hi Jeff, _HEAPOK is unknown to mingw 1.0 (which is the official release). Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/

Hi, This minor patch clarify matters in the CFEBuildInstrs.html file in my view. Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/

Hi Reid, The error still exists. However, looking on the function in Win32/Path.cpp: -------------- void sys::CopyFile(const sys::Path &Dest, const sys::Path &Src) { if (!::CopyFile(Src.c_str(), Dest.c_str(), false)) ThrowError("Can't copy '" + Src.toString() + "' to '" + Dest.toString() + "'"); } -------------- I

Sorry, I forgot to give all you guys my credit, too. Without your help - especially from Jeff, Morten, Reid and Chris, to name a few, this wouldn't have succeded. Just for fun, I ran from a windows command prompt the fibinacci.exe with the argument of 10 and it returned 55. All in all, something lives. Great! :) >From: "Henrik Bach" Date: Fri, 28 Jan 2005 23:26:02 +0100

Yes, Chris you're right. It seems that my << operator for int64_t is missing in my '/opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc' file. Which ordinary version of GCC are you working with and how do your definition of the << operator for int64_t look like? /Henrik > >Here is an excerpt from the config.log for LLVM: > >configure:19451: checking for int64_t

Uh... shouldn't a Win32 port use the Win32 API? On Tue, 14 Sep 2004 02:11:51 +0200 "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > Hi > > Here is my first patches to the Win32 platform. > > They compile on the mingw platform. > > I haven't test them yet, but I thought it will best to put them in the save, > just in case... > >

No, Chris, I'm not buying that argument, due to I've tweaked /usr/include/types.h a little bit, so the configuration and compilation of the cfrontend would be correct: /* * 64bit type for BSD compatability */ #ifdef __GNUC__ typedef long long int quad_t; typedef unsigned long long int u_quad_t; typedef long long int int64_t; typedef unsigned long long int u_int64_t;

Hi again Does cygwin support shared libraries. And if not, how did you port llvm on this issue? /Henrik >From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Tue, 27 Jul 2004 00:41:53 +0200 > >Hi, > >I get this error: >------------------ >ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >ToolRunner.cpp:396: