similar to: [LLVMdev] build broken on linux/amd64

If you look in X86JITInfo.cpp, you'll find CompilationCallback. I'm not sure about CompilationCallback2. In any event, the code is conditionally compiled and that might be tripping things up on Cygwin. Reid. On Mon, 2005-05-30 at 17:17 +0100, Aaron Gray wrote: > Consistant error building LLVM on Cygwin from CVS :- > > make[2]: Entering directory

Hi LLVM'ers, I can't figure out why I get this error: -------------------------------------------------- c:/MinGW/bin/../libexec/gcc/mingw32/3.4.2/collect2.exe -Bdynamic -o c:/projects/build/MinGW/llvm-1-1/Debug/bin/llc.exe /mingw/lib/crt2.o c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/crtbegin.o -Lc:/projects/build/MinGW/llvm-1-1/Debug/lib -Lc:/projects/build/MinGW/llvm-1-1/Debug/bin

I first sent this to the Clang dev list, but they told me to come here: ---------- Forwarded message ---------- From: Ruben Van Boxem <vanboxem.ruben at gmail.com> Date: 2010/12/31 Subject: LLVM on Windows MSVC 10 To: cfe-dev at cs.uiuc.edu Hi, I'm trying to build svn LLVM with Visual Studio 2010: cd build cmake .. -G"NMake Makefiles" nmake and several link steps fail

2010/12/31 Francois Pichet <pichet2000 at gmail.com>: > I don't normally build using nmake.. but I just tried and it worked 100% > here. > Are you sure you are using the trunk? > > On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com> > wrote: >> >> I first sent this to the Clang dev list, but they told me to come here:

'collect2.exe' is an internal version of 'ld' called by GCC The GCC command line is :- g++ -I/usr/build/llvm-2/tools/llc -I/usr/src/llvm/tools/llc -I/usr/build/llvm-2/ include -I/usr/src/llvm/include -I/usr/build/llvm-2/include -I/usr/src/llvm/incl ude -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W -Wwrite-strings -Wno-unused -g -D_DEBUG -v -o /usr/build/llvm-2/Debug/bin/llc.exe

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: >>> I'm trying to build svn LLVM with Visual Studio 2010: >>> >>> cd build >>> cmake .. -G"NMake Makefiles" >>> nmake >>> >>> and several link steps fail due to a missing symbol: >>> >>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error

On 19/08/2009, at 4:00 AM, Anton Korobeynikov wrote: > Hello, Nathan > >> or if it should be a configure test, which might be safer. Are there >> any x86 platforms (other than apple) that don't need PLT-indirect >> calls? > Yes, mingw. However just tweaking the define is not enough - we're not Ok, so configure might be the way to go then, maybe something

I don't normally build using nmake.. but I just tried and it worked 100% here. Are you sure you are using the trunk? On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com>wrote: > I first sent this to the Clang dev list, but they told me to come here: > > > ---------- Forwarded message ---------- > From: Ruben Van Boxem <vanboxem.ruben at

I did not report this first error earlier as I thought it trivial. Basically it looks like something odd is happening with the configuration and 'include/llvm/config/config.h' Getting this error on building the tools on a fresh Cygwin install and update :- $ make tools-only make[1]: Entering directory `/usr/build/llvm/lib/System' llvm[1]: Compiling Path.cpp for Debug build In file

Hello, Following some recent messages about building with Visual Studio 2010, I have gotten most things to compile in release mode on 64b windows 7. (Mainly the few errors with 0 -> nullptr in the second argument of the pair constructor, and making an ECValue constructor public). I'm falling at the last hurdle though when it comes to the final link: 1>------ Build started: Project:

Consistant error building LLVM on Cygwin from CVS :- make[2]: Entering directory `/usr/build/llvm/tools/llc' llvm[2]: Compiling llc.cpp for Debug build llvm[2]: Linking Debug executable llc /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30506): In function `_GLOBAL__D__ZN7 6_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_DD38501517X

"Bill O'Hara" <billtohara at gmail.com> writes: > 1>LLVMX86CodeGen.lib(X86JITInfo.obj) : error LNK2019: unresolved > external symbol X86CompilationCallback referenced in function "public: > virtual void (__cdecl*__cdecl > llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void > *)))(void)" (?getLazyResolverFunction at

Hi Morten, If you can make the VS2005 project files availiable on the net then I can test them as I have VS2005 now, so then with Chris'es okay then they could be distributed with LLVM. Thanks, Aaron ----- Original Message ----- From: "Morten Ofstad" <morten at hue.no> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, January 26,

I am not sure if it is the correct solution, but the attached patch fixes the problem. The build now fails when linking lto: relocation R_X86_64_32 against `(anonymous namespace)::EmittedInsts' Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: amd64.patch Type: application/octet-stream Size: 1176 bytes Desc: not available URL:

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)

Reid, Getting the same error again :-( /usr/gcc/gcc-3.4.3/libexec/gcc/i686-pc-cygwin/3.4.3/collect2.exe -Bdynamic --dl l-search-prefix=cyg -o /usr/build/llvm-2/Debug/bin/llc.exe /lib/crt0.o -L/usr/bu ild/llvm-2/Debug/lib -L/usr/build/llvm-2/Debug/bin -L/usr/gcc/gcc-3.4.3/lib/gcc/ i686-pc-cygwin/3.4.3 -L/usr/gcc/gcc-3.4.3/lib/gcc/i686-pc-cygwin/3.4.3/../../..

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp 0x000000FFC - after mov

On 02/03/2010 01:08 PM, Kristaps Straupe wrote: > Hello again. > > I still think that you are wrong. Realignement with and esp,-16 not > always changes stack poiner. If esp is already aligned to 16 byte > boundary, it will not change! Take a look at following example. > Assume esp has value 0x000001000 at start of X86CompilationCallback > function. Then execution of it will

The project files need frequent updating. I cannot maintain VS2005 project files, so while they could be distributed with LLVM, they will become broken fast. Also, VS2003 and VS2005 project and solution files cannot coexist in the same directories, further complicating matters. Aaron Gray wrote: > Hi Morten, > > If you can make the VS2005 project files availiable on the net then I

Hi! We are running llvm jit x86 on MS Visual Studio 2005. It seems there is a bug in asm code in function X86CompilationCallback in file X86JITInfo.cpp. Current code sets stack pointer to invalid value in instruction "and esp, 16". Depending on current stack pointer value it sometimes overwrites ecx and edx registers with next three lines. We have fixed this problem by changing this