similar to: [LLVMdev] Temporally shutdown few clang-x86_64-darwin11 builders

I've got a simple workaround which obviously everyone will figure out: mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crti.o crti.o mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crt1.o crt1.o mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crtn.o crtn.o My real question concerns whether or not I should file a bug report against Debian not having a

Seeing as GCC 4.6 works without breaking to build LLVM instead of Clang I think I'm going to bug the Debian proper to make it easier for Clang/LLVM to get the linker update changes. After all, Debian's breaking an awful lot of stuff lately so it seems reasonable for them to add this to their To Do List. - Marc On 08/24/2011 07:15 PM, Eli Friedman wrote: > On Wed, Aug 24, 2011 at

File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt set(LLVM_TARGET_DEFINITIONS Hexagon.td) tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) tablegen(LLVM HexagonGenAsmWriter.inc -gen-asm-writer) tablegen(LLVM HexagonGenDAGISel.inc -gen-dag-isel) tablegen(LLVM HexagonGenCallingConv.inc -gen-callingconv) tablegen(LLVM

Linking CXX executable ../../../../bin/lldb Scanning dependencies of target lldb-platform [100%] Building CXX object tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o *../../../../lib/liblldb.so.3.5: undefined reference to `llvm::SmallPtrSetImpl::SmallPtrSetImpl(void const**, unsigned int, llvm::SmallPtrSetImpl&&)'** **clang: error: linker command

I keep getting this error upon building: > Linking CXX executable ../../bin/opt > ../../lib/libLLVMTarget.so: error: undefined reference to > 'llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData > const*, llvm::MachineInstr const*) const' > ../../lib/libLLVMTarget.so: error: undefined reference to >

On Wed, Aug 24, 2011 at 6:36 PM, Marc J. Driftmeyer <mjd at reanimality.com> wrote: > I've got a simple workaround which obviously everyone will figure out: > > mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crti.o crti.o > mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crt1.o crt1.o > mdriftmeyer at horus:/usr/lib$ sudo ln -s

On Jun 8, 2012, at 12:52 PM, Marc J. Driftmeyer <mjd at reanimality.com> wrote: > I keep getting this error upon building: > >> Linking CXX executable ../../bin/opt >> ../../lib/libLLVMTarget.so: error: undefined reference to 'llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData const*, llvm::MachineInstr const*) const' >>

Debian's response I enclose to see if this helps out: > reassign 639214 general > forcemerge 637232 639214 > quit > > Hi Marc, > > Marc J. Driftmeyer wrote: > >> With the most recent changes of moving the object files under >> /usr/lib/x86_64-linux-gnu/ the linker to build Clang/LLVM breaks. >> >> A workaround is to add symlinks for crt1.o,

On Thu, Nov 29, 2012 at 9:41 AM, Joe Abbey <jabbey at arxan.com> wrote: > I know this process is well documented here > http://llvm.org/docs/GettingStarted.html > > But man do I love scripting things: > > LLVM Getting Started (See http://llvm.org/docs/GettingStarted.html) > ./getttingStarted.sh [-clang] [-compiler-rt] [-test-suite] [-branch branch] > [-dir path] [-r

My apologies. Shouldn't it just be removed since it is now in a subdirectory? On 12/15/2011 11:38 PM, Marc J. Driftmeyer wrote: > File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt > > set(LLVM_TARGET_DEFINITIONS Hexagon.td) > > tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) > tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) > tablegen(LLVM

On 1/8/2013 5:45 PM, Chris Lattner wrote: > >some version of Clang and later (Freebsd folks?). FreeBSD 9.1 uses GCC 4.2.1 and Clang 3.0, although I have some doubts about the clang, at least on PPC32. Trunk clang compiled with the system clang crashes on code that the same trunk clang compiles fine when built with gcc. It may as well be a source problem in trunk though... -Krzysztof

Looks like your lldb is being compiled in C++11 mode and your llvm wasn't perhaps? -eric On Sat, Nov 23, 2013 at 12:57 AM, Marc Driftmeyer <mjd at reanimality.com> wrote: > Linking CXX executable ../../../../bin/lldb > Scanning dependencies of target lldb-platform > [100%] Building CXX object > tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o

So instead of being able to quickly extend scripting via Bash or C Shell you'd prefer people learn Python to extend any functionality? Cygwin is well tested on Windows. Shell Scripting [Bash, C, Ksh, ZShell, etc] is pervasive in UNIX/Linux and won't be replaced by Python or Perl. Simple automated scripts requiring the memory footprint of python just to make it work in Windows seems

*System:* Debian Linux Sid/Unstable amd64 *LLVM/Clang:* Trunk *Scenario:* In the past couple of days I've been compiling against trunk I get two separate and spurious hang ups with CMake. *Note:* I build against more than just X86 follow along the progress of other platforms, though just building for X86 produces the same results below. *Assumption:* Configure cmake with prior built

03.12.2012, 11:44, "Marc J. Driftmeyer" <mjd at reanimality.com>: > One of the most conservative distributions is Debian. RHEL/CentOS is more conservative. RHEL 6 ships Python 2.6.6, RHEL 5 (which is still widely used) ships 2.4.3 -- Regards, Konstantin

Hi there, I just wanted to install gfortran via homebrew on mac os x mountain lion. It uses the package gcc-42-5666.3-darwin11.pkg for installation. Unfortunately I recognized that this package is not available anymore. But the google cache told me that it was available at http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg some time ago (the site was cached at Sep 30th). Does anybody

Hi, the subject says it all... After some experimenting, I got a bit confused as far as what the proper thing to do might be.... I build llvm/clang from trunk sources on OSX Lion 10.7.3 (i.e. x86_64-apple-darwin11.3.0 to speak GNU's platform-ese) where I also have successfully built a fsf-gcc 4.6.2 (and lately a 4.7 for that matter) from sources. Now, I think I understand that by playing

One of the most conservative distributions is Debian. The python_defaults package has moved to 2.7.3 in Sid and 2.7.3~rc2-1 in Wheezy (Debian 7.0 now on its 4th beta and soon to be release candidate status). I personally run Sid/Unstable in order to get general release builds of LLVM/Clang > 2.9, never mind 3.2. It seems reasonable to target 2.7.3 as the oldest python release. - Marc J.

Seeing as I'm using OS X and Debian Sid which is on GCC 4.7.2-5 which moved over to Wheezy for Debian 7 release it seems more reasonable to target that than using Ubuntu's 4.6.x which is never more conservative than Debian on releases. - Marc P.S. I'm more interested in actually seeing if this will improve an actual smooth installation of libc++ with llvm/clang/compiler-rt trunk

Anton Korobeynikov <anton at korobeynikov.info> writes: > I think cmake system lacks many features of autoconf system. In > addition to already said thing, I think the major missing thing is > cross-compilation support. > You can easy cross-compile llvm/clang via standard > --build/--host/--target flags. If you will show that this will be > possible by cmake - then