search for: 3.0svn

Graham, good morning. To build LLVMHello on cygming, you should configure llvm with --enable-shared . Even with enable-shared, you might build lib/Transforms/Hello manually. (yeah, on cygming, LLVMHello should depend on tools/llvm-shlib) And, you'd be better to build with --enable-optimized. With enable-shared, llvm-shlib tends to fail with too many debug symbols. HTH, ...Takumi

Thankyou Takumi, Without --enable-optimized I get a"File too big" error from the linker: ... llvm[1]: Linking all LLVMLibs together for LLVM-3.0svn /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: /cygdrive/c/Users/Graham/home/projects/llvm_cygwin3/tools/llvm-shlib/Debug+Asserts/LLVM-3.0svn.a.o: too many sections (59747)

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what

I've built LLVM/Clang from svn under Cygwin on Windows 7. I'd like to build on the LLVMHello pass example, however, when I try: $ cd $LLVM/lib/Transforms/Hello $ make I receive a large number of errors which start with: llvm[0]: Linking Debug+Asserts Loadable Module LLVMHello.dll /cygdrive/c/Users/Graham/home/projects/llvm_cygwin/lib/Transforms/Hello/Debug+Asserts/Hello.o: In function

Hi Kent, My guess is you are getting some new bit of info in your object files and your ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string

I am debugging the memory issue that manifests itself like this: *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** ======= Backtrace: ========= /lib/libc.so.6(+0x6c501)[0x4f6501] /lib/libc.so.6(+0x6dd70)[0x4f7d70] /lib/libc.so.6(cfree+0x6d)[0x4fae5d] ../app/app.OWS(_ZNSt8_Rb_treeIjjSt9_IdentityIjESt4lessIjESaIjEE5eraseESt17_Rb_tree_iteratorIjES7_+0x4b)[0x83de6eb]

As directed from http://vmkit.llvm.org/get_started.html, I'm getting: checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for shared library run path origin... /bin/sh: ./config.rpath: No such file or directory done checking for iconv... yes

In r134967 it still worked, and in r137742 it now doesn't. I used such flags: --enable-assertions --enable-shared --enable-libffi --enable-debug-runtime --enable-debug-symbols --disable-optimized Before build would create directory tools/llvm-shlib under the build tree. Now it is missing. Yuri

Yuri, on which host? 2011/8/17 Yuri <yuri at rawbw.com>: > In r134967 it still worked, and in r137742 it now doesn't. > I used such flags: --enable-assertions --enable-shared --enable-libffi > --enable-debug-runtime --enable-debug-symbols --disable-optimized > > Before build would create directory tools/llvm-shlib under the build > tree. Now it is missing. In my

Apple clang version 3.0 (tags/Apple/clang-211.9) (based on LLVM 3.0svn) Target: x86_64-apple-darwin10.8.0 It's part of the Xcode 4.2b7 package. Shall I try to compile it on my own? Thanks, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Mon, 3 Oct 2011 10:19:04 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at

Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0

On Oct 3, 2011, at 4:42 AM, Somorjai, Akos wrote: > I'm trying to use this warning to check the vtable problem. Here's an example > > In mem.hpp > > class > AA { > // Construction / destruction: > protected: > AA (); > AA (const AA&); // Disabled > public: > virtual ~AA (); > }; > > In mem.cpp > > #include "mem.hpp" >

On Tue, Nov 22, 2011 at 11:32 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > As directed from http://vmkit.llvm.org/get_started.html, I'm getting: > > checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld > checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no > checking for shared

Here you go: http://www.cornwarning.com/xfer/jccolor.o (from the jpeg library...) jccolor.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 432 SUBSECTIONS_VIA_SYMBOLS Load command 0 cmd LC_SEGMENT_64 cmdsize 312 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000900

Thanks for the response. Since X11 is by default installed on OS X when the developer tools are installed. Running autoconf fixed the issue with configure not finding X11, although I did not check why the configure script did not have the correct path (I'm assuming this was the case). Next I'm on to the gtk+ dependencies which I'm going to try to solve with macports if I have to. I

Thanks, Bob! I guess we should be expecting a 4.2.1 update after clang 3.0 has been released, shouldn't we? Best, Akos From: Bob Wilson <bob.wilson at apple.com<mailto:bob.wilson at apple.com>> Date: Thu, 20 Oct 2011 08:46:38 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: > Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) > >

Hi, I have been trying all day long to get the following 5 line file to compile: test.ll: declare void @llvm.gcroot (i8**, i8*) define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 10) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc (i64) If I do > llc test.ll I get ld: in

Hi all, I am having some problems when loading plugins using opt -load=xxx, due to missing symbols. I am using a statically linked version of LLVM under Mac OS X 10.7, and I have pinpointed the problems to two separate causes: 1) opt should not be stripped during installation. When installing Release versions, opt is stripped, removing symbols which might get needed by the plugins. In my case,

I've tracked down a problem I've been having with llvm code ensconced in shared libraries that priori to r139934, on OS X 10.7.1-10.7.2 worked fine. Since r139934, which involves a configure change (and configure.ac), resulting in the default clang compiler to be used when building clang, and llvm, it seems I can no longer deposit llvm code involving jit, and IR gen functionality into