Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] No crt2.o file found"
2006 Dec 21
1
[LLVMdev] No crt2.o file found
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.
2006 Dec 18
0
[LLVMdev] No crt2.o file found
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
2006 Dec 18
0
[LLVMdev] No crt2.o file found
/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
2006 Dec 17
0
[LLVMdev] No crt2.o file found
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
2006 Dec 16
0
[LLVMdev] No crt2.o file found
I managed to get the llvm tool chain compiled on my windows machine
using mingw a couple of weeks ago.
When I tried to run the simple test case provided in the documentation I
ran into a problem of missing object files.
I attempted to compile the simple hello.c hello world application.
Unfortunately I get the following
$ llvm-gcc hello.c -o hello.exe
ld: crt2.o: No such file: No such file
2006 Dec 23
0
[LLVMdev] No crt2.o file found
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
2006 Dec 19
0
[LLVMdev] No crt2.o file found
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
2009 Oct 02
0
[LLVMdev] Cannot find crt2.o with llvm-gcc on windows/mingw
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
2005 Nov 01
4
[LLVMdev] Re: Still can't compile backend or frontend on, Windows
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
2000 Apr 17
2
segfault cause found
>Win95. Unfortunately, the encoder_example segfaults. I get the same
>results from Cygwin as well.
Problem solved! (Or rather, worked around...) The problem with the segfault
appears to have indeed been with alloca. There is a function _alloca in
libgcc.a that comes with the mingw32 distribution of gcc-2.95.2. After
examining the generated assembly code from envelope.c (and others),
2005 Oct 30
1
[LLVMdev] Re: LLVMdev Digest, Vol 16, Issue 24
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
2005 Nov 04
0
[LLVMdev] Re: Still can't compile backend or frontend on, Windows
>From: Matthew Bromberg <mattcbro at earthlink.net>
>Date: Tue, 01 Nov 2005 16:21:34 -0500
>The JIT compiler is of course of great interest, but I'm also interested in
>static compilation and in fact this seems to me one of the intriguing
>features of LLVM, the fact that it can support both static and dynamic
>languages, with a common optimization infrastructure. (I
2020 May 14
1
NUT control of vCenter & vServer?
That's certainly on the list of options. I'm doing data gathering right now
to see what options there are. I'd prefer not to rashly decide to run off
in a direction only to discover this is already a Solved Problem.
nomad
On Thu, May 14, 2020 at 1:13 PM Bart J. Smit <bart at smits.co.uk> wrote:
> What about the REST API to do a graceful shutdown of your VM’s and the
>
2007 Jun 24
0
[LLVMdev] alloca on Win32
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
2007 Jun 24
1
[LLVMdev] alloca on Win32
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
2014 Jul 07
0
mdiskchk and WinPE, file found \o/
Op 2014-07-07 om 09:24 schreef Jerome Levy:
> From: sha0.miller at gmail.com, Date: Mon, 7 Jul 2014 00:14:27 -0400
> > From: Jerome Levy, Sent: Sunday, July 06, 2014 19:04
> >
> > > Thus the rub: The exe seems to have disappeared from winbin as well. It's
> > > there, but downloads as a zero-byte file.
> >
> > Please try clicking the
2014 Jul 08
2
mdiskchk and WinPE, file found \o/
Baaaaah, phooey! Yeah, get two e-mail clients like I have: Mozilla
Thunderbird for Geert and Microsoft Outlook for everyone else I frequently
correspond with, who don't want to scroll just to read what's new. Some
things just aren't universal, even if one thinks they should be. What a
world. - Shao
-----Original Message-----
From: Syslinux [mailto:syslinux-bounces at zytor.com] On
2014 Jul 08
0
mdiskchk and WinPE, file found \o/
On Tuesday, July 8, 2014, 5:32:53, Shao Miller wrote:
> Baaaaah, phooey! Yeah, get two e-mail clients like I have: Mozilla
> Thunderbird for Geert and Microsoft Outlook for everyone else I frequently
> correspond with, who don't want to scroll just to read what's new.
That's why you trim the irrelevant quotes, and only leave in the parts
you're replying to.
--
<
2007 Jun 24
5
[LLVMdev] alloca on Win32
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
2009 Nov 20
1
2.6.31+2.6.31.4: XFS - All I/O locks up to D-state after 24-48 hours (sysrq-t+w available) - root cause found = asterisk
Package: asterisk
Version: 1.6.2.0~dfsg~rc1-1
See below for issue:
On Wed, 21 Oct 2009, Justin Piszcz wrote:
>
>
> On Tue, 20 Oct 2009, Justin Piszcz wrote:
>
>
>>
>>
>> On Tue, 20 Oct 2009, Dave Chinner wrote:
>>
>>> On Mon, Oct 19, 2009 at 06:18:58AM -0400, Justin Piszcz wrote:
>>>> On Mon, 19 Oct 2009, Dave Chinner wrote: