similar to: [LLVMdev] Building LLVM under Mingw. Part I: tools-only

Hello, Everyone. Now I have some spare time and I've decided to build LLVM on Mingw. I've grab the latest 1.7 release (not CVS snapshot). Here are some issues fixed during the build. Now I'm preparing gcc build. So, I think, there will some other "parts" 1. Prerequisites 1.1 GCC 3.4.5 from mingw.org site. $ gcc --version gcc.exe (GCC) 3.4.5 (mingw special) Copyright (C)

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:45:02 PM: JC> Yes, I know mingw doesn't support dbghelp. I can still rant about it :) ;) Well. Maybe this library will be included in some next versions of mingw's win32api package. Anyway, we can make such library just "on-fly" from the corresponding .dll. JC> This is what's already there. What changed? Maybe

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:50:08 PM: JC> You will. You haven't gotten that far yet. It shows up as a crash JC> running gccas. Ok. Switched to 2.1 JC> As for ld crashing, I have no suggestions. It seems to be bug in bfd/cofflink.c file of libbfd. I can even name the function, where weird thing happens. But it's out of my possibilities to debug this

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

Hello, Jeff. You wrote Saturday, January 22, 2005, 3:57:28 AM: JC> Reid, the binary/text mode is a valid issue. This set of flags worked for me: std::ios_base::out | std::ios_base::trunc | std::ios_base::binary Yes, there are open issues with std::ios_base::binary, but llvm are not affected with them now. JC> I have successfully used a bytecode file on Windows that was created JC> on

Hello, Aaron. You wrote Sunday, April 30, 2006, 12:01:10 AM: AG> The Cygwin LLVM release (OPTIMIZED_ENABLED) version triggers a bug in LD AG> (BFD binutils) this may well be common to MinGW as well. Seems so, since debug version of llc.exe builds smoothly. Do you have more information about this issue? -- With best regards, Anton mailto:asl at math.spbu.ru

Hello, Aaron. You wrote Sunday, April 30, 2006, 1:34:16 AM: AG> I traced the code its easy enough to find the error message in the bfd code. Hmm. This seems to be another bug. I've just got access to null address in linker and it's crashed. No error message at all. -- With best regards, Anton mailto:asl at math.spbu.ru Sunday, April 30, 2006 1:48:15 AM

On Mon, 2004-08-30 at 21:46, Jeff Cohen wrote: > This isn't my day... > > gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' > Bisoning FileParser.y > Flexing /usr/home/llvm/obj/../utils/TableGen/FileLexer.l > gmake[2]: Leaving directory `/usr/home/llvm/obj/utils/TableGen' > gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' >

On Mon, 30 Aug 2004 21:27:26 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Mon, 30 Aug 2004 20:48:45 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > When I ran configure after updating, I get various errors. First: > > > > % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc > > checking for a

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Mon, 30 Aug 2004 21:46:42 -0700 >FileParser.tab.c: In function `int Fileparse()': >FileParser.tab.c:2043: error: syntax error before `goto' > >The offending lines bison generated are: > >/*----------------------------------------------------. >| yyerrlab1 -- error raised explicitly by an action. |

I want to play around with the GLR support in the recent bison, so I simply fixed the skeleton. On Tue, 31 Aug 2004 07:31:25 -0700 Reid Spencer <reid at x10sys.com> wrote: > On Mon, 2004-08-30 at 21:46, Jeff Cohen wrote: > > I'm using bison 1.875. But it worked the last time, so I don't know why > > it doesn't work now. Deleting the __attribute__ clause fixes

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

Hello, Everyone. This is just brief description on building llvm-gcc4 with mingw32. It's definitely non error-free and contains many "hacks", which should be eliminated in the future. 1. Prerequisites We're building in the folowing configuration: 1.1 GCC 3.4.5: gcc -v Reading specs from f:/research/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with:

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

Hello, Greg. You wrote Saturday, May 13, 2006, 11:12:26 PM: GP> The problem is that it can't find some symbols: (SymSetOptions, GP> SymInitialize, SymGetModuleBase, SymFunctionTableAccess, etc.) GP> I looked on the Web and these functions are in Dbghelp.lib. GP> Are they also in libimagehlp.a? Yes, they are. At least im mingw-runtime 3.9 (I'm using this version). GP>

Hi, I'm able to build the llvm tools on the MinGW platform: burg, fpcmp, tblgen, llvm-as, llvm-dis, opt, gccas, llc, llvm-link, lli, gccld, llvm-stub, analyze and extract. I wonder if these tools are sufficient to start build the cfrontend? Henrik. _________________________________________________________________ Undg� pop-ups med MSN Toolbar - http://toolbar.msn.dk hent den gratis!

Hello, I supose that a new version of pigeonhole is on the way because version 0.4.13 does not compile against dovecot 2.2.23 This is the error that I get gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../../src/lib-sieve -I../../../src/lib-sieve/util -I../../../src/lib-sieve/plugins/environment -I/home/jc/rpmbuild/BUILD/dovecot-2.2.23/src/imap

On 31/03/2016 02:06, Stephan Bosch wrote: > Hi, > > Op 3/30/2016 om 5:34 PM schreef Juan C. Blanco: >> Hello, I supose that a new version of pigeonhole is on the way because >> version 0.4.13 does not compile against dovecot 2.2.23 >> >> This is the error that I get >> >> gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. >>

I am trying to do my first asterisk install on a SuSE 9.1 box, using the asterisk-update script mentioned a few days ago on this list. I did read the 'quickstart' document on onlamp.com, and made sure the following packages were installed via yast: bison, cvs, gcc, kernel-source, libtermcap-devel, ncurses-devel, newt-devel, openssl096b, and openssl-devel. The SuSE 9.1 DVD contained

Anton Korobeynikov <asl at math.spbu.ru> writes: [snip] > 2) Problem: Complains about gthr-default.h file. > Resolution: Grab gcc/gcc/gthr-win32.h file and copy it to gthr-default.h ... so --enable-threads=win32 is broken... good to know. > 3) Problem: Complains about "CL_ObjCXX" and simular ("CL_") during > compilation