similar to: Building llvm so it can be installed by other users

Hi All, I need to build clang/llvm from source on an Ubuntu Linux system, in order to build the gnustep Objective-C environment. I was able to build clang using cmake without a problem (following the instructions at clang.llvm.org/get_started.html), but when I tried to build gnustep, I found that clang failed to compile an autoconf-generated program. The compile error in the configure log was:

Building the BlocksRuntime isn’t supported via CMake at the moment. It should be pretty straightforward to make it work, but it currently isn’t supported. -Chris > On Sep 29, 2015, at 9:45 AM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As far as I know the makefile in there isn't the makefile that gets executed during the cmake build -- cmake generates its

Hi Jon, > Build directories aren't easily redistributable, nor are they really meant to be. Install directories on the other hand can be, provided you build with the right options, and package together all the dependencies. > > Is there a particular reason why you want to distribute your build dir instead of your install dir? Oops, you are right: I think it's the install

Hi Chris and Alex, Many thanks for these replies. > I dug a little deeper into the history here. It looks like the blocks runtime hasn’t built in the CMake build system in a long time, and I don’t think it has ever been supported in the autoconf system. > > Support for building it with CMake was removed in April 2012 along with the old CMake build system (r154059) because it was

> Unfortunately you’ll need to either modify the LLVM build system to build it, or you’ll need to build it yourself by hand. We don’t currently support building the blocks runtime. Thanks! I'm working on a modified build now. Out of curiosity: is cmake still the preferred way to build on Linux? You mentioned that the doc is out-of-date, so I thought perhaps there might be a newer way to

On Fri, Aug 04, 2017 at 04:40:44PM -0600, Jonathan Roelofs wrote: > Might be a helpful exercise for you to try building vanilla clang with > runtimes for the host, before worrying about how to build everything for > your baremetal case: > http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary So I did. :o) It was fun realizing how much Release type reduces LD

Hello, thank you for the thoughts. > Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem > especially)? They certainly aren't perfect but they are considerably > better than what was there before. Okay, the documentation has come a long way since 3.0 although it still needs a bit of polish. > I wouldn't say that much "important functionality is plain

On 04/12/2019 06:31 PM, Tom Stellard via llvm-dev wrote: > On 04/12/2019 04:28 PM, AiChi via llvm-dev wrote: >> Hi, >> >> I'm currently working on one of my team's project to build LLVM full clang toolchain (Clang, libcxx, libcxxabi) on a CentOS machine. >> >> Previously we compiled our codebase with llvm-toolset-7/clang++, which by default takes stdlibc++

I am forwarding this post to the Shorewall Users mailing list. The email address ''support@shorewall.net'' is reserved for sending large or confidential attachments to the Shorewall support team. See http://www.shorewall.net/support.htm -Tom -------- Original Message -------- Subject: Question Date: Mon, 20 Oct 2008 11:30:04 +0000 From: Raul <rfunez@polar.es> To:

I am an actual end user of LLVM who builds it from source and not a developer of it so I think I have an important perspective that is not represented here. Also I am pretty sure the llvmdev mailing is heavily biased and might not reach actual end users of LLVM. I use the Autotools build system for a number of reasons. If compromises or reasonable workarounds could be found I would be okay with

Recently I have been building LLVM and Clang from the distribution using gcc 4.9.2. With the new 5.0.0 rc2 that is giving warning messages during the compilation. I have been trying out some other compilers. gcc 5.2 with -std=c++11 This works, although there are still some warnings. gcc 6.4 and gcc 7.1 fail with errors such as this in building libcxxabi as follows: Command:

Hi all, I am having some some trouble with LLVM 3.8... I built it with GCC 4.8.2 with cmake and no special CXX/C flags. That means in case of GCC that RTTI is switched on, I believe. However, building my MCJIT application against the just built LLVM and linking results in: libqdp.a(qdp_llvm.o):(.rodata._ZTIN4llvm8FCmpInstE[_ZTIN4llvm8FCmpInstE]+0x10): undefined reference to `typeinfo for

http://bugzilla.netfilter.org/show_bug.cgi?id=780 Summary: nfnl_handle_packet() doesn't respect NLMSG_DONE Product: libnfnetlink Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: libnfnetlink AssignedTo: netfilter-buglog at

The documentation for the arima function in the package stats has a slight error. It references: Ripley, B. D. (2002) Time series in R 1.5.0. R News, 2/1, 2–7. [1]http://www.r-project.org/doc/Rnews/Rnews_2002-1.pdf This should be: Ripley, B. D. (2002) Time series in R 1.5.0. R News, 2/2, 2–7. [2]http://www.r-project.org/doc/Rnews/Rnews_2002-2.pdf Anyone know who I should tell about this?

On 12/27/2017 04:43 PM, David Miller wrote: > From: Jason Baron <jbaron at akamai.com> > Date: Fri, 22 Dec 2017 16:54:01 -0500 > >> The ability to set speed and duplex for virtio_net in useful in various >> scenarios as described here: >> >> 16032be virtio_net: add ethtool support for set and get of settings >> >> However, it would be nice to be

Our out-of-tree LLVM compiler is configured and built on Linux, but I cannot get it to run under the Windows 10 Linux Subsystem. When run in this context it reports a crash: warning: Error disabling address space randomisation: Success warning: linux_ptrace_test_ret_to_nx: PTRACE_KILL waitpid returned -1: Interrupted system call Program received signal SIGSEGV, Segmentation fault.

On Fri, Aug 04, 2017 at 04:03:35PM -0600, Jonathan Roelofs wrote: > > > 1) Pick a directory as your sysroot > > ~/arm-sysroot > > > > > 2) Install the libc headers there (without having built it) > > What I did was mv musl-*/include ~/arm-sysroot/usr/include. > > I think you need to copy them, not move them. On a new directories and fresh untar of musl, I

I am an experienced Linux developer but a Wine newbie. Recently I have been exploring the possibility of using CMake-2.8.1 and MinGW-4.5.0 in a Wine-1.1.42 environment (the backported Debian Lenny packages from WineHQ) to check that CMake-based build systems I use for various software projects work properly for that Windows platform. I am collecting notes for a wiki entry I am planning to write

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron <jbaron at akamai.com> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com> --- hw/net/virtio-net.c | 54 +++++++++++++++++++++--------------------- include/hw/virtio/virtio-net.h |

I just checkout release_38 branches of llvm, clang and polly and built it on and x86 Ubuntu with cmake: CMAKE_BUILD_TYPE="Debug" CMAKE_INSTALL_PREFIX="$HOME/toolchain/install/llvm-3.8" LLVM_TARGETS_TO_BUILD="X86" cmake -G "Unix Makefiles" \ -DBUILD_SHARED_LIBS="ON" \ -DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE \