similar to: [LLVMdev] another llvm-gcc-4.2 compilation problem

Thanks for the suggestion, Andre. I downloaded GNAT GPL 2007, and followed the directions on your web page. Now I get a lot of C++ errors. In fact, the output I captured to a log file is over six megabytes just from the start of the problem command to the termination of the make. I'm obviously not going to include it all here, but the command and the first few errors are copied below.

hi, I try to build hello.cpp using both llvmg++ and GNU g++, the generate llvm bytecode's size is about 960K, and the size of binary code generated by g++ is only 13K. Could anyone explain the difference between the two result? BWT: I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp the llvmG++ reports warnings too, it shows: ----------------------------- [yue at RH9

This is a forward of a question from the SourceForge LLVM forum. If anyone has experience with Cygwin and building the C front-end there, please reply and CC Alex. --- Post by Alex Vinokur below --- =============== Windows 2000 GNU gcc 3.3.3 (cygwin special) =============== ./configure ./make I have got compilation error ------------------------------- make[1]: Entering directory

I posted this message first. But it was missing so I post again. I think there is a some bug in build configration files. Can you check up the following errors and fix it? The error has no concern with UTF-8 patch. Environment : CentOS 4.3 x86_64 Sungsoo Kim ---------------------------------- [root at saturn xapian-core-0.9.4_svn6707]# make ... ... mkdir .libs/libxapian.lax/libqueryparser.a

On Sat, 23 Dec 2006, Roman wrote: > How to solve this problem? Java isn't supported. Use --enable-languages=c,c++ -Chris > $ 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

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

On Mon, 14 May 2007, Nicolas Geoffray wrote: > Hi everyone, I am using linux/ppc and after porting llvm's jit for this > architecture, I am currently trying to compile llvm-gcc on it. > > I have gcc 4.1.1 and use llvm-gcc from cvs. This looks like you're compiling llvm-gcc3, which is quite dead by now. Please follow these instructions: http://llvm.org/docs/CFEBuildInstrs.html

Hi everyone, I am using linux/ppc and after porting llvm's jit for this architecture, I am currently trying to compile llvm-gcc on it. I have gcc 4.1.1 and use llvm-gcc from cvs. Compilation fails and the message is: gcc -O2 -DIN_GCC -DDEFAULT_TARGET_MACHINE=\"powerpc-unknown-linux-gnu\" -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long

Report by Eric Lindblad 28-08-2015 http://www.ericlindblad.blogspot.com As of Windows 8.1 MS has discontinued enabling for Interix, so perhaps there is little or no interest in this e-mail's subject matter. NB: As far as possible languages for xapian-bindings I only have be able to compile earlier versions of Tcl with a static library on Interix 3.5, Perl versions fail 'make check',

Question by Eric Lindblad 05-09-2015 http://www.ericlindblad.blogspot.com I would enquire if anyone has an opinion on whether it might be a possibility that adding the following #ifdef in certain xapian-core-1.2.21 /common and/or /backends files following the string #include <sys/types.h> might move closer towards resolution the 'ambiguous overload' issue. +#ifdef __INTERIX +#

Hi guys Is some one able to explain me, why these errors emerge: gmake[2]: Entering directory `/usr/local/src/llvm/lib/VMCore' Compiling AsmWriter.cpp AsmWriter.cpp: In function `void WriteConstantInt(std::ostream&, const llvm::Constant*, bool, std::map<const llvm::Type*, std::string, std::less<const llvm::Type*>, std::allocator<std::pair<const llvm::Type* const,

Here is an excerpt from the config.log: configure:19451: checking for int64_t configure:19476: gcc -c -g -O2 conftest.c >&5 configure:19479: $? = 0 configure:19482: test -s conftest.o configure:19485: $? = 0 configure:19496: result: yes configure:19511: checking for uint64_t configure:19536: gcc -c -g -O2 conftest.c >&5 configure:19539: $? = 0 configure:19542: test -s conftest.o

On Wed, 7 Jul 2004, Henrik Bach wrote: > This tweak seems to work. > > As far as I can see, correct me if I'm wrong, it is the compiler, that can't > figure out which std::basic_ostream to use. Why? What I'm saying is that it appears that your implementation of operator<< is not functional or is missing. You said that you are using GCC on internix. Is it possible

any ideas what library has these symbols lang_eh_catch_all get_pointer_alignment validate_arglist i get these linker errors when trying to link llvm-gcc: make[1]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[2]: Entering directory

No, Chris, I'm not buying that argument, due to I've tweaked /usr/include/types.h a little bit, so the configuration and compilation of the cfrontend would be correct: /* * 64bit type for BSD compatability */ #ifdef __GNUC__ typedef long long int quad_t; typedef unsigned long long int u_quad_t; typedef long long int int64_t; typedef unsigned long long int u_int64_t;

Yes, Chris you're right. It seems that my << operator for int64_t is missing in my '/opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc' file. Which ordinary version of GCC are you working with and how do your definition of the << operator for int64_t look like? /Henrik > >Here is an excerpt from the config.log for LLVM: > >configure:19451: checking for int64_t

I have download source ?1.10? from the internet and build it into lib Then I create a project as the helpdoc said I using vc2005(vc8) The source in my test project is as follow??copy from the helpdoc? #include <xapian.h> #include <iostream> using namespace std; int main(int argc, char **argv) { // Simplest possible options parsing: we just require three or more

Hi, After a svn/cvs update I get the following errors when building the frontend. Anyone that sees the same ? http://gcc.gnu.org/svn/gcc/branches/apple/trunk/gcc/expr.h /* APPLE LOCAL begin radar 4441049 */ extern tree objc_v2_component_ref_field_offset (tree exp); extern tree objc_v2_bitfield_ivar_bitpos (tree exp); /* APPLE LOCAL end radar 4441049 */ mentions APPLE, is it only working on

On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: > On x86-64 linux, in stage 2, I get: > > c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o f951 \ > fortran/arith.o