similar to: [LLVMdev] [llvm-commits] remove libtool from build system

On OS X 10.5.5 I get an error that ld doesn't support -export-dynamic: dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ ../src/configure --prefix=`pwd`/../install && make VERBOSE=1 ... dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ make VERBOSE=1 for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools docs; do \ if [ ! -f

I'm trying to build the 2.5 prerelease on my MacBook, and I'm getting a bus error in tblgen: $ rm -r * && ../src/configure --prefix=`pwd`/../install && make -j1 VERBOSE=1 ENABLE_OPTIMIZED=0 ... llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td /Users/jyasskin/src/llvm-2.5/obj/Debug/bin/tblgen -I /Users/jyasskin/src/llvm-2.5/src/lib/VMCore -I

On Dec 16, 2008, at 10:34 AM, Jeffrey Yasskin wrote: > I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also > checked out llvm. Both are synced to r61075. hi Jeffrey, This patch should have fixed the problem: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071210.html Please update and try again, sorry for the breakage! -Chris

I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also checked out llvm. Both are synced to r61075. I'm using Apple's gcc 4.0.1: $ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++

I am trying to build LLVM from source in FreeBSD 8.4. Here are the steps i carried out 1. Downloaded the source from http://llvm.org/releases/3.8.0/llvm-3.8.0.src.tar.xz 2. Extracted the source into a folder. 3. Created a build directory and inside it ran $ cmake ../llvm-3.8.0.src 4. Started the build using $cmake --build . It throws the following error

Hi all, On my Fedora 10 x86-64 the current svn dies in the following way: /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In function `llvm::TGLexer::getNextChar()': /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: undefined reference to `llvm::TGSourceMgr::FindBufferContainingLoc(llvm::TGLoc) const'

Hello, Neal > You may want to note that you need glibc-devel.i386 to build. Otherwise you > get error on /usr/include/gnu/stubs-32.h missing. Do you have pure 64 bit system? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

You may want to note that you need glibc-devel.i386 to build. Otherwise you get error on /usr/include/gnu/stubs-32.h missing.

I made a simple edit to TGlexer.h, which is part of TableGen. Then, in Visual Studio, I asked it to build Tablegen. I got the following output: 1>------ Build started: Project: LLVMTableGen, Configuration: Release x64 ------ 1>Main.cpp 1>TGLexer.cpp 1>TGParser.cpp 1>LLVMTableGen.vcxproj -> D:\LLVM\Build\Release\lib\LLVMTableGen.lib ========== Build: 1 succeeded, 0 failed, 3

Hi, Thanks for the information. Is it possible to compile LLVM 3.8 in FreeBSD 10.x and eventually use/run it on 8.4. Our production environment is running 8.4 and we cannot update it. Thanks, Sushil Pangeni On Wed, Jun 22, 2016 at 2:01 PM, Dimitry Andric <dimitry at andric.com> wrote: > You cannot build any llvm or clang releases after 3.4 on FreeBSD 8.x > natively, as it is not

LLVMers, The 2.5 pre-release is available for testing: http://llvm.org/prereleases/2.5/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary (please compile llvm-gcc with fortran if you can). 2) Run make check, send me the testrun.log 3) Run "make

Current llvm release 2.8 branch at r115409 is broken on x86_64-apple-darwin10. #!/bin/bash -ev export LD=`xcode-select -print-path`/usr/bin/ld xcode-select -print-path ulimit -s `ulimit -s` ulimit -s mv ../clang-2.8 ./tools/clang mkdir ../llvm_objdir cd ../llvm_objdir ../llvm-2.8/configure --prefix=/sw --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --with-gmp=/sw

Hm, I also note that: $ file /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as: Mach-O 64-bit executable x86_64 Why's the i386 package have an x86_64 binary in it? That could explain why it doesn't work on darwin9. On Fri, Mar 19, 2010 at 9:49 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Hi Tanya, > > On darwin9, the

Hi Tanya, On darwin9, the binaries in the darwin10 packages give: $ /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as --help dyld: unknown required load command 0x80000022 Trace/BPT trap That could be unavoidable, of course. Also, could you document what build mode the packages use (or release both Debug and Release-Asserts packages)? Since +Asserts and -Asserts have different ABIs, I'd have

Hi Jack, I didn't get this error. Could you try again? Is it one of the release candidates in particular that's failing? -bw On Oct 2, 2010, at 8:04 AM, Jack Howarth wrote: > Current llvm release 2.8 branch at r115409 is broken on x86_64-apple-darwin10. > > #!/bin/bash -ev > export LD=`xcode-select -print-path`/usr/bin/ld > xcode-select -print-path > ulimit -s

Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib

I experienced FAIL: /localtmp/astifter/llvm/llvm-svn/test/FrontendC/2007-03-27-VarLengthArray.c Failed with exit(1) at line 1 while running: /nfs/a5/astifter/astifter/llvm/llvm-svn-obj/../llvm-svn-install/bin/llvm-gcc -emit-llvm -w -S /localtmp/astifter/llvm/l lvm-svn/test/FrontendC/2007-03-27-VarLengthArray.c -o - | /bin/grep {getelementptr inbounds \[0 x i32\]} child process exited abnormally

>> Daniel's comments are also good. > > …success! Looks like I spoke a bit too soon. Everything works as far as the fat binaries are concerned, except that -mmacosx-version-min is set to the host’s OS version, not that of the SDK, causing errors when it tries to link against 10.6’s versions of libraries instead of 10.5’s. This patch appears to solve that; it uses the OS version

The 2.7 binaries are available for testing: http://llvm.org/pre-releases/2.7/pre-release1/ You will also find the source tarballs there as well. We rely on the community to help make our releases great, so please help test 2.7 if you can. Please follow these instructions to test 2.7: To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it

I guess I should add this to the long list of things Apple has broken that used to work well on NEXTSTEP (the operating system that has been turned into OS X). Now that you mention it, I remember having a problem getting flac to cross-compile in one build step, so I just did the manual lipo glue that you talked about. I assumed it was only because I was too lazy to figure out how to