similar to: [LLVMdev] No crt2.o file found

Hello, Matthew. > > I figured that just copying the mingw crt*.o files would not > > be a good idea. > /Why not? Mingw32 crt does not depend on LLVM. /I rashly copied all the *.o files from my mingw\lib directory to the llvm\lib directory. This does enable the hello world binary to compile and to function correctly. However the byte code file does not work correctly giving:

Hello, Matthew > I managed to get the llvm tool chain compiled on my windows machine > using mingw a couple of weeks ago. Have you tried to build llvm-gcc by yourself? > $ llvm-gcc hello.c -o hello.exe > ld: crt2.o: No such file: No such file or directory Normally crt*.o files are built during normal gcc build process (llvm-gcc as well). However, mingw32 runtime has its own crt*.o

/Have you tried to build llvm-gcc by yourself? /Not with the recent build. In times past I failed miserably at this using cygwin. Maybe I should try again? /Normally crt*.o files are built during normal gcc build process (llvm-gcc as well). However, mingw32 runtime has its own crt*.o files, which are included with binary distribution of llvm-gcc4 (mingw32 variant). /I thought that would be

Hello, Matthew. > My file size matches the patched file. I haven't figured out how to get 7-zip to give me checksum information on windows. Use md5sum utility. It can be successfully found via google. > I rashly copied all the *.o files from my mingw\lib directory to the llvm\lib directory. > This does enable the hello world binary to compile and to function correctly. Strange.

Hello, Matthew. > I figured as much. It would be great to get the mingw branch on > windows working, since it avoids the cygwin dll and some restrictive > licensing issues. Mingw32 branch is quite ok as the time of writing this lines :) I was able to compile Qt with llvm-gcc4 1.9 and everything was fine. So, I suppose something went wrong during unpacking tarball or something like

Hello, Matthew. > Not with the recent build. In times past I failed miserably at this using cygwin. Maybe I should try again? Well, actually I mean: whether llvm-gcc binary under consideration was built by yourself or you're using pre-built binaries from downloads section? If you're using llvm-gcc4 binary from downloads section, mingw binary is included into tarball, you might find

Hi all, After being able to build llvm and llvm-gcc on windows/mingw, I am running into problems with linking. It seems llvm-gcc isn't able to find crt2.o. Ronald

Hello, Matthew. > Hmm there is no llvm-gcc directory in either the patch file or what made it > on to my system. Furthermore there are no crt*.o files after my build until > I put them in the lib directory, which where they are in the patch file. > Again the clean must have removed them. Well. Actually you should have 2 trees: 1. One you're building LLVM in. There is directory

On Jun 18, 2008, at 12:27 PM, Yaroslav Kavenchuk wrote: > Mike Stump wrote: >>> Is it possible to use dynamic library (*.so *.dll) from bytecode? >>> If "yes" - how? >> >> dlopen? That's be one way. Also, most systems have shared libraries >> in /usr/lib and these routines are meant to be linked against and >> used. For example, on

Mike Stump wrote: >> Is it possible to use dynamic library (*.so *.dll) from bytecode? >> If "yes" - how? > > dlopen? That's be one way. Also, most systems have shared libraries > in /usr/lib and these routines are meant to be linked against and > used. For example, on darwin, there sinf is resolved from a shared > library, you declare it and call it, as

llvmdev-request at cs.uiuc.edu wrote: >Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > >You can reach the person managing the list at

Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack

The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using

Chris Lattner wrote: >> $ lli gcd_ui.bc >> ERROR: Program used external function '__gmpz_init_set_ui' which could >> not be resolved! >> >> This application has requested the Runtime to terminate it in an >> unusual way. >> Please contact the application's support team for more information. > > Try: lli -load /path/to/foo.so gcd_ui.bc

llvmdev-request at cs.uiuc.edu wrote: >Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > >You can reach the person managing the list at

Hi, This is probably an easy question, but I could not find the answer to it. I'm working on a LLVM back-end for the EHC compiler (a Haskell compiler). Currently there is a C back-end and I would like to reuse the primitive library functions from this back-end. So I have compiled C sources in a .o file and I would like to call these from my LLVM code. If I declare these primitive functions

Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had

Hello, llvm-dev. thank you for your interest in my question. Currently, I compiled simple c source code (hello.c) in lunux and windows, and I tried to simple test . first case: hello.bc (compiled with "-emit-llvm" on windows) -> lli.exe(linux). second case: hello.bc (compiled with "-emit-llvm" on linux) -> lli.exe(windows). second case return good result. but First case

Hi, I'm just trying to get started with a simple example with LLVM under windows. I downloaded the mingw binaries from the website and would like to compile a program. (PS: The mingw binaries did not come with any documentation on what they are and how to use them) I used the online code generator (http://llvm.org/demo/index.cgi) to compile hello world: #include <stdio.h> int main() {