similar to: [LLVMdev] Building llvm under cygwin

If you're building llvm-gcc4, you don't need the runtime libraries, so I'd just stick with the "tools-only" build and declare success. If you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :) However, the problem appears to be your PATH variable. In your path you have the following directory: C:/Program Files/Microsoft DirectX SDK (June

> > If you're building llvm-gcc4, you don't need the runtime libraries, so > I'd just stick with the "tools-only" build and declare success. If > you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :) I switched to llvm-gcc4 but when I run make from obj folder i run into folowing errors: Can't find a library with no dependencies at

Hi there, I'm trying to build llvm under cygwin running under windows xp, and have struck the following problem: -- llvm: tools-only built ok -- cfrontend: built ok -- llvm: full build failed at the following point: make[3]: Entering directory `/cygdrive/d/3rd-party/llvm/runtime/GCCLibraries/crtend' Compiling crtend.c to bytecode Compiling listend.ll to bytecode Linking comp_main.bc

It claims it was last updated 2007-01-04 06:47:31 -0400 (Thu, 04 Jan 2007). It should be close to TOT tomorrow. Cheers, -- Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070104/9cecae71/attachment.bin>

Chris Lattner wrote: >On Sun, 15 Aug 2004, Robert Feldt wrote: > > > >>However, I wonder if someone supplies pre-built cfrontend binaries for >>cygwin? >> >> > >Nope, we don't have one yet, sorry. > > > >>I followed the instructions and tried to build them myself but get >>when building the cfrontend. Any ideas? >>

The machine is a Dell workstation with xeon processors. The OS is RHEL 4 AS x86_64 gcc version is 3.4.6 I checked out the llvm-gcc from svn, configured with ../llvm-gcc/configure --prefix=$HOME/llvm-gcc-install --enable-llvm=$HOME/llvmobj/ --enable-languages=c,c++ --enable-checking --disable-shared --disable-multilib and get the following error message: make

On Mon, Aug 16, 2004 at 01:07:39PM +0200, Robert Feldt wrote: > However, when I go back to rebuild llvm, reconfigure, setting the > CFEINSTALL dir, then make it can build the tools ok but not the > runtime: [snip] > Compiling crtend.c to bytecode > Files/ATI: not found [snip] > I don't understand the error message since I see no reference to > Files/ATI. Any clues? Can

gcc 3.4.x builds LLVM incorrectly on x86_64. gcc 4.0 will get you much farther, but the llvm-test regression tests still have massive problems. Zhongxing Xu wrote: > The machine is a Dell workstation with xeon processors. The OS is RHEL > 4 AS x86_64 > gcc version is 3.4.6 > > I checked out the llvm-gcc from svn, configured with > ../llvm-gcc/configure

Hi Chris, > Also note, LLVM 1.4 will be released in the next few days, so if waiting is > an option, you might choose to do so. Alright, I've got llvm and llvm-gcc from RELEASE_14 cvs and tried building it under cygwin. 1) The first problem is with llvm in SysUtils.c: int executeProgram(const char *filename, char *const argv[], char *const envp[]) { ................ execveTy

On Jan 9, 2007, at 9:48 PM, Jeff Cohen wrote: > gcc 3.4.x builds LLVM incorrectly on x86_64. > > gcc 4.0 will get you much farther, but the llvm-test regression tests > still have massive problems. Please file bug reports on these. Thanks! Evan > > Zhongxing Xu wrote: >> The machine is a Dell workstation with xeon processors. The OS is >> RHEL >> 4 AS

I do all my LLVM stuff on x86_64 without trouble... I have a nightly tester up, and its only getting a few regressions currently, and I think some of those have to do with the radical changes going on in LLVM-land currently, and others with no one having done support for x86-64 in debugging output. (this is at least most of what I've seen, ymmv). Also, for the record, I have found both gcc

Already have concerning gcc 3.4: http://llvm.org/bugs/show_bug.cgi?id=1056 As for llvm-test issues, quite frankly I don't know how well they're expected to work on x86_64. No one has jumped in and said they run fine on their x86_64 system. Maybe they're code generator bugs, or maybe they're portability issues for FreeBSD (though I never saw such massive problems with 32-bit

Something last night broke the build on Darwin PPC. Possible Gabor's check-in? -bw Begin forwarded message: > From: admin at spang.apple.com (admin) > Date: March 4, 2009 3:56:10 AM PST > To: wendling at apple.com > Subject: PPC Nightly Build Result > > /Volumes/SandBox/NightlyTest/llvmgcc42.roots/llvmgcc42~obj/obj- > powerpc-powerpc/./prev-gcc/xgcc

Happy New Year all, I've just updated to the latest CVS version and cygwin port is still broken. When building full llvm: llvm[3]: Compiling crtend.c for Debug build (bytecode) llvm[3]: Compiling listend.ll for Debug build llvm[3]: Linking comp_main.bc component... assertion "(Result->isFirstClassType() || Result == Type::VoidTy || isa<OpaqueType>(Result)) && "LLVM

Problem 2: Configure: ../src/configure --prefix=/tmp/llvm/install --disable-threads --disable-nls --disable-shared --enable-languages=c,c++ --disable-c-mbchar --program-prefix=llvm- $ make make[1]: Entering directory `/tmp/llvm3/llvm/build/libiberty' make[2]: Entering directory `/tmp/llvm3/llvm/build/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving

Could you provide a list of all tests failing for you? You can just grep the output from make for 'FAILED!'. I've fixed 5 of them so far... 275 to go... Chandler Carruth wrote: > I do all my LLVM stuff on x86_64 without trouble... I have a nightly > tester up, and its only getting a few regressions currently, and I > think some of those have to do with the radical

How to solve this problem? $ make make[1]: Entering directory `/tmp/llvm3/llvm/build/libiberty' make[2]: Entering directory `/tmp/llvm3/llvm/build/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/llvm3/llvm/build/libiberty/testsuite' make[1]: Leaving directory `/tmp/llvm3/llvm/build/libiberty' make[1]: Entering directory

Hi, > I am confused. Shouldn't the gcc 4.2 front-end build behave > just like the FSF gcc build. The first stage builds the compilers > and the second stage rebuilds them using those from the first > stage? the FSF gcc requires you to build the C compiler (I think - will check). Thus a newly built C compiler is always available to build later stages. We can't reasonably

Hi Bill, this might be a latent bug related to PPC. I have no such machine to access atm., but I shall be able to reproduce the problem when back at home. (In about 4 hours). I keep you informed. Cheers, Gabor On Mar 4, 7:57 pm, Bill Wendling <wendl... at apple.com> wrote: > Something last night broke the build on Darwin PPC. Possible Gabor's   > check-in? > > -bw

Hi, in trying to build an llvm-gfortran on linux from today's gcc4 SVN, I get the following link errors that didn't show up on OS X. This is also using LLVM CVS from this morning. They appear to mostly be related to CodeWarrior compatibility code, but a couple are less obvious. What's the best way to fix this? I'm stuck without my powerbook for at least three weeks and I'd