similar to: [LLVMdev] libllvm on windows

On 05/31/2010 10:02 AM, John Lask wrote: > I am looking to use llvm on windows. I know there is a pre-compiled llvm > windows distribution, but this does not seem to provide libllvm. The > software that I am looking to use makes use of libllvm (it is unix > based, but I would like to port it to windows). I really did not wish to > spend my time compiling llvm (i.e. installing

Török Edwin wrote: > On 05/31/2010 10:02 AM, John Lask wrote: > > I am looking to use llvm on windows. I know there is a pre-compiled > > llvm windows distribution, but this does not seem to provide libllvm. > > The software that I am looking to use makes use of libllvm (it is unix > > based, but I would like to port it to windows). I really did not wish > > to

Hi, What is the status of building LLVM trunk with Visual Studio 2010 (32/64-bit)? Were the build problems of LLVM 2.7 fixed? Best regards, --Edwin

hi ambika, I am not sure about this solution as i just started working in this field. How about taking analogy of a problem which ask us to find nearest common parent of two nodes in a tree. Let me know if I can be corrected. - Anubhav intern IIT M B. Tech 4th year CSE VIT University, Vellore. On 31 May 2010 22:30, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

Hello, Lately, I have been working on moving Debian & Ubuntu packages to a stage2 build. This means that, instead of shipping llvm-toolchain packages built with gcc, we are rebuilding everything a second time using the newly built clang. Now, when pushed to Debian, it caused some unexpected issues in particular with rust reported here:

On 2011-02-14 20:39, Talin wrote: > > > On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin <rengolin at systemcall.org > <mailto:rengolin at systemcall.org>> wrote: > > I think this deserves a blog post... > > I'd like to wait until I get some feedback - I don't know yet if anyone > is having trouble building or running the thing... Hi Talin,

Hi, For openSUSE Linux we switched to cmake to build llvm and this comes with its own set of problems which are mostly workaroundable but today I got a report saying that we lost libLLVM-3.3.so in the transition. Turns out that cmake build system does not create this file even when shared libraries are enabled. See http://llvm.org/bugs/show_bug.cgi?id=15493 for a reported bug about this. It

On 2011-02-14 20:58, Török Edwin wrote: > On 2011-02-14 20:39, Talin wrote: >> >> >> On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin <rengolin at systemcall.org >> <mailto:rengolin at systemcall.org>> wrote: >> >> I think this deserves a blog post... >> >> I'd like to wait until I get some feedback - I don't know yet if

OK I figured out what the problem was - I assume you are trying to compile under Snow Leopard? There is a problem with linking against wxWidgets because the prebuilt binaries for wxWidgets are compiled in 32-bit mode, and the default compilation mode in Snow Leopard is 64 bits. See this article for an explanation: http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard

Hi, all I use llvm-gcc -O4 to compile SPEC 2000, some benchmarks can't be built successfully, such as 164.gzip, 175.vpr etc. The error messages are as follows. .. zh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip bits.o: file not recognized: File format not recognized collect2: ld returned 1 exit status specmake: *** [gzip] Error 1 specmake options 2> options.err |

On 2009-07-15 23:24, Dale Johannesen wrote: > On Jul 15, 2009, at 11:52 AMPDT, Stuart Hastings wrote: > > >> We've had a lot of churn in all the trunks (llvm, llvm-gcc, clang) >> recently, and the testing buildbots have been failing repeatedly. >> >> I spoke with Chris this AM, and he suggested we have a "stabilization >> day." Please avoid

Hi folks, I’m trying to port some code built on top of LLVM/Clang to Windows, however I just discovered that the precompiled versions from releases.llvm.org are missing all the libLLVM* and libclang* dlls. Also, some tools (e.g. opt) are missing on Windows as well. I’m curious whether it’s a technical limitation (i.e. certain things don’t work on Windows), or something else? For the others out

On 2011-02-14 23:33, Török Edwin wrote: > On 2011-02-14 23:11, Talin wrote: >> OK I figured out what the problem was - I assume you are trying to >> compile under Snow Leopard? > > No, I should've mentioned it: this is Debian unstable x86_64, and > wxwidgets is definetely 64-bit. > Maybe its just something messed up on my system (had 2.9.1 in > /usr/local/).

On 2009-12-23 08:22, Li Shengmei wrote: > > Hi, all > > I use llvm-gcc –O4 to compile SPEC 2000, some benchmarks > can’t be built successfully, such as 164.gzip, 175.vpr etc. > > The error messages are as follows. > > > > …… > > zh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip > > bits.o: file not recognized: File format not recognized

On 2011-02-14 23:11, Talin wrote: > OK I figured out what the problem was - I assume you are trying to > compile under Snow Leopard? No, I should've mentioned it: this is Debian unstable x86_64, and wxwidgets is definetely 64-bit. Maybe its just something messed up on my system (had 2.9.1 in /usr/local/). Willtry removing that and reinstalling 2.8. --Edwin

I am getting this error on FreeBSD-8.1 (amd64): llvm[1]: Linking Debug+Asserts Shared Library libLLVM-2.8svn.so /tmp/llvm-svn/llvm-objects/Debug+Asserts/lib/libLLVMSystem.a(Program.o)(.text+0xa2b): In function `llvm::sys::Program::Execute(llvm::sys::Path const&, char const**, char const**, llvm::sys::Path const**, unsigned int, std::basic_string<char, std::char_traits<char>,

On Wednesday 15 July 2009 15:43, Török Edwin wrote: > How about starting simple, and just auto-tagging builds that work? > Could be done per OS/arch, and one global tag when all buildbots pass. We've talked about this before and I've been working on setting up such a system. Unfortunately, I can't figure out why my buildbots fail to configure llvm-gcc. Is there a link to the

Now that autoconf is going away soon, I figured I'd try building using CMake. I checked out llvm, cfe and lldb from the SVN server, and followed the basic build instructions. cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/tools/llvm/svn_head -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON ../llvm Everything worked well, and in