similar to: [LLVMdev] fail to build LLVM GCC front-end

I followed the instructions in llvm_gcc's README.LLVM file, but not exactly the same. the following is what I have done with LLVM: ./configure --disable-optimized --enable-checking make make install (Successful) now the llvm-gcc: cd /home/username mkdir obj mkdir install cd obj ../llvm-gcc/configure --prefix=`pwd`/../install --program-prefix=llvm- --enable-llvm=/home/username/llvm-2.7/Debug

On Apr 28, 2010, at 9:31 PM, Jiandong Wang wrote: > I try to build it on Ubuntu9.04, but in vain. There are errors: > > ... > ... > make[3]: *** No rule to make target `/home/username/llvm-2.7/Debug/include/llvm/Intrinsics.gen', needed by `llvm-convert.o'. Stop. > make[3]: Leaving directory `/home/username/obj/gcc' > make[2]: *** [all-stage1-gcc] Error 2 >

On Thu, Apr 29, 2010 at 2:17 AM, Jiandong Wang <computerhenu at gmail.com> wrote: > I followed the instructions in llvm_gcc's README.LLVM file, but not exactly > the same. > > the following is what I have done with LLVM: > ./configure --disable-optimized --enable-checking > make > make install > (Successful) > > now the llvm-gcc: > cd /home/username >

Is 'make check' supposed to work with llvm-gcc? I get the following: autogen -T /users/dag/projects/cascade/compiler/llvm-gcc/fixincludes/check.tpl /users/dag/projects/cascade/compiler/llvm-gcc/fixincludes/inclhack.def Your shell is '/bin/tcsh'. AutoGen will attempt to use 'sh' /bin/sh ./check.sh /users/dag/projects/cascade/compiler/llvm-gcc/fixincludes/tests/base

Thank you, I did try that and got the following error: checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libiberty] Error 1 make[1]: Leaving directory `/home/ghoang/llvm-test/llvm-gcc-2.8-build' make: *** [all] Error 2 I also tried adding --disable-libiberty but make would fail even earlier

> this comes directly from your system headers (/usr/include/bits/select.h) > and as such doesn't really have anything to do with llvm-gcc: iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are presented presented in one version and does not - in another, thus the difference... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Hi Anton, >> this comes directly from your system headers (/usr/include/bits/select.h) >> and as such doesn't really have anything to do with llvm-gcc: > iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are > presented presented in one version and does not - in another, thus the > difference... IIRC the fixincludes hack was done so that the asm would not

> it has been fixed in clang but not in llvm-gcc. I believe I fixed it in llvm-gcc via fixincludes :) Not the best way, but... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

hi all, I was trying to build the latest LLVM gcc front end and it failed. rajika@:~/project/llvm/dst-directory$ svn info | grep URL URL: http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk configure option: ../dst-directory/configure --prefix=/usr/local/ --enable-llvm=/home/rajika/project/llvm/llvm-objects it gave me the following errors ../../dst-directory/gcc/llvm-convert.cpp:1163: error:

Is there any plans for addressing the regression... https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15899 in the 3.2.1 release? In the fink project, I had to resort to creating a fixincludes subdirectory containg a local copy of the offending Rinterface.h header with the missing extern on the declaration of R_running_as_main_program restored in order to suppress duplicate symbols during the

Greg Pettyjohn <gregp at ccs.neu.edu> writes: > I'm using a little shell script: [snip] > confopts="--prefix=$PREFIX" > confopts="$confopts --disable-threads" > confopts="$confopts --disable-nls" > confopts="$confopts --disable-shared" > confopts="$confopts --enable-languages=c,c++" >

Did you update llvm and build that first? -Tanya On May 21, 2008, at 10:29 PM, Rajika Kumarasiri wrote: > hi all, > I was trying to build the latest LLVM gcc front end and it failed. > > rajika@:~/project/llvm/dst-directory$ svn info | grep URL > URL: http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk > > configure option: ../dst-directory/configure --prefix=/usr/local/

Hello all, I am trying to install the llvm-gcc front end to use it in one of my projects, but I got stuck.. I am working on a Sun workstation: SunOS xxx 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Fire-V240 and I have gcc version 3.4.6: Reading specs from /sw/gcc-3.4.6/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: /.scratch/andjo/lsw/src/gcc/gcc-3.4.6/configure

Since we are fast approaching the 10th, I thought it appropriate to report this "bug" with the build despite not having worked around it. Build environment is *Summary:* When building llvm-gcc with a arm-apple-darwin target on i686-pc-cygwin, make fails because child calls to configure have an errant semicolon that causes the --srcdir parameter to be ignored by the configure script.

Hi all, (CC''ing dtrace-discuss as an FYI+workaround) I''m using dtrace -h to define provider probes for my application, and it wraps the resulting probe provider definitions in an #if _DTRACE_VERSION. Everything works fine for cc/CC, but gcc/g++ (gccfss v4.2.0) doesn''t seem to define it and the provider call macros expand to nothing instead. A diff shows that gcc uses

Hi! In current LLVM CVS: llvm/projects/Stacker/Makefile.common.in llvm/projects/sample/Makefile.common.in llvm-java/llvm-java/Makefile.common.in have line: include $(LLVM_OBJ_ROOT)/Makefile.common that have line: include $(LLVM_OBJ_ROOT)/Makefile.config (also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in) and llvm/Makefile.config.in have lines: INSTALL_SH :=

On Mon, 14 Feb 2005, Reid Spencer wrote: > Personally, I don't think LLVM projects should need much in the way of > autoconf stuff. They certainly don't need to replicate things like > install-sh and mkinstalldirs. I'd vote for taking these out of the > projects rather than making the makefiles deal with them. I think in > most cases these are just historical artifacts

I currently have a slightly modified llvm-2.0 source tree (from the release tarball). I checked out poolalloc into the projects directory and attempt to configure it, but I keep getting errors. I would understand if there were problems building it (since it may require a different version of llvm), but it should at least configure. Specifically, I've tried the following commands: >

Hi I'm installing R with the standard commands: ./configure make make check make dvi to create DVI versions make pdf to create PDF versions make info to create info files make install make install-dvi make install-info make install-pdf Everything works fine apart from "make

> > 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