similar to: Questions about the methods of compilation.

Fixing one bug uncovers the next one... To reproduce: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> The result: C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: Can't move './libgcc.a-000003' to './libgcc.a-000002': Cannot create a file when that file already exists. So apparently, we're trying to move one file on top of another. The

Hi, For lllvm 3.7 and before BUILD_SHARED_LIBS=ON would produce versioned shared libs like libLLVMLTO.so (symlink) libLLVMLTO.so.3.7 (symlink) libLLVMLTO.so.3.7.0 (real file) now it just builds an unversioned libLLVMLTO.so file which I believe is a problem because when a program links to llvm it generates a runtime dependency on libLLVMLTO.so instead of libLLVMLTO.so.3.7.0 which will break

Yep, you found another bug. Unlike Unix, Windows does not allow a file to be implicitly replaced via renaming. I'll fix it. Greg Pettyjohn wrote: > Fixing one bug uncovers the next one... > > To reproduce: > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > > The result: > C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: Can't move

Hello, Is there any CMake variable available to build LLVM libs as static libraries. I found one -DLIBCLANG_BUILD_STATIC=ON but what if I want libLTO.a instead of libLTO.dylib ? *Vivek Pandya* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151214/1e03efc9/attachment.html>

I checked out llvm/trunk today and found that it failed to build successfully on Linux when 'configure' was invoked with '--disable-shared' and CFLAGS included '-static'. The attached patch modifies a few Makefiles to prevent attempts to build shared libraries when ENABLE_SHARED is not set to 1. Apply the patch in the LLVM root directory with 'patch -p1 ...'

Anton, Thanks for your comment. 2nd patch attached. - s/SharedDir/SharedLibDir/g - move prefix=cyg sunk into if(cygwin or mingw) arigato gozaimasu...Takumi * Additional issues - You may build LLVMHello.dll but I don't modify lib/Transforms/Makefile. Because making LLVMHello.dll requires the library LLVM.dll, but it oughta be on the way to making libs at building

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

I'm trying to do a simple build from the git 8.0.0 sources. The sources seem to build OK but a link step fails from running out of memory. I need some clues how to figure out where the bottleneck might be. The cmake command is: cmake -G Ninja                                          \     -DLLVM_TARGETS_TO_BUILD=X86                         \    

Good evening, Michael. 2010/9/5 Michael Spencer <bigcheesegs at gmail.com>: > Do you know what the exact problem is? It would be best to fix the > Makefile instead of moving it. And sense it is a transformation, the > build system is broken if you _have_ to move it. I am sorry, I don't understand what *the exact problem" is. I can describe facts; - Hello is the only

Hi, llvmdev! The diff attached takes the features of OpenBSD binutils into account (which needs --whole-archive) and makes build with ENABLE_SHARED successful. -------------- next part -------------- Index: tools/llvm-shlib/Makefile =================================================================== --- tools/llvm-shlib/Makefile (revision 117443) +++ tools/llvm-shlib/Makefile (working copy) @@

1. I got the tools to build. Yay! 2. I got past all the annoying trouble with not finding header files. Yay! Now I'm having problems with this: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid I'm investigating this with the debugger and so far I've learned that

On Sat, 6 May 2006, Greg Pettyjohn wrote: > Now I'm having problems with this: > > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid > I've tracked this down in the debugger. It is indeed a bug. The problem is that Path::isValid() will reject a string

Greg, Looks like Jeff Cohen already fixed this in CVS. Please update and give it another shot. Thanks, Reid. On Sat, 2006-05-06 at 16:43 -0400, Greg Pettyjohn wrote: > > On Sat, 6 May 2006, Greg Pettyjohn wrote: > > > Now I'm having problems with this: > > > > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > >

Vladimir, It is as same as freebsd :) See also http://llvm.org/bugs/show_bug.cgi?id=8434 I will commit them fused tomorrow, if no one objects. ...Takumi 2010/10/27 Vladimir Kirillov <proger at uaoug.org.ua>: > Hi, llvmdev! > > The diff attached takes the features of OpenBSD binutils into account > (which needs --whole-archive) and makes build with ENABLE_SHARED >

Chris Lattner wrote: > On Sat, 6 May 2006, Reid Spencer wrote: >> Looks like Jeff Cohen already fixed this in CVS. Please update and give >> it another shot. > > Is this fixing the issue, or just papering over it? Why are we trying > to load an archive member without a path set? We're not. It's just a sentry value. > > -Chris > >> On Sat,

Hi Takumi, > Any feedbacks are welcome. > Have fun! This seems to be pretty useful addition to LLVM on windows! And it seems the only painless way to make plugins working, yay! For me the patch looks pretty good. One minor thing: could you please rename SharedDir => SharedLibDir Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

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

On Sat, 6 May 2006, Reid Spencer wrote: > Looks like Jeff Cohen already fixed this in CVS. Please update and give > it another shot. Is this fixing the issue, or just papering over it? Why are we trying to load an archive member without a path set? -Chris > On Sat, 2006-05-06 at 16:43 -0400, Greg Pettyjohn wrote: >> >> On Sat, 6 May 2006, Greg Pettyjohn wrote: >>

So the fundamental problem I'm trying to solve is how get my cfrontend build configured properly. The usual symptom of an incorrect configuration is the inability to find various header files. Here's some example spew: $ /home/llvm_home/llvm-gcc-build/gcc/xgcc -v -B/home/llvm_home/llvm-gcc-build/gcc/ -Bc:/msys/1.0/mingw32/bin/ -Bc:/msys/1.0/mingw32/lib/ -isystem

Hi, Is there a tutorial on how to get started with writing link-time optimization passes? The documentation at http://www.llvm.org/docs/LinkTimeOptimization.html explains the design of the LTO interface, but does not explain where to start writing code. Would my pass go inside libLTO.a or is it separate from libLTO.a? What I would like to be able to do is traverse through the entire