similar to: Building a program with LLVM on Unix

There are several m4 macros that let you write autoconf detection for llvm. I recently needed to implement one. Have a look here: https://github.com/google/autofdo/blob/master/m4/ax_llvm.m4 Diego. On Wed, Mar 23, 2016 at 12:48 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Building LLVM itself involves Cmake, but what's the best way to build a C++ >

I'm writing a C++ program that uses LLVM, and trying to build it with autotools. Thanks to Diego Novillo, there is an M4 macro that detects llvm-config: https://github.com/google/autofdo/blob/master/m4/ax_llvm.m4 How do I use it? Given that I've written a basic configure.ac that can compile a basic C++ program, how do I modify it to make use of the macro? And should the macro be copied

Jack's correct about moving this to autoconf at gnu.org. However, you can start by cutting and pasting the configure.ac bits from the same github repo I pointed you to earlier today. The actual commit that brought those changes may be easier to use as a template. https://github.com/google/autofdo/pull/30/commits/0029f4be825f851b9d99bcd19dcb34fd59f1775e On Wed, Mar 23, 2016 at 4:35 PM,

Given that the LLVM API changes constantly, any reasonable C++ program may very well compile properly against only one specific version/release of LLVM. The probability that you can properly build against whatever some user has installed on some arbitrary system approaches zero. If you accept this, then you likely work around it by configuring and installing an appropriate version of LLVM and its

When you say 'configuring and installing an appropriate version of LLVM and its libraries yourself' - that is indeed what I did on my own machine (Ubuntu 14.04 apt-get thinks 3.4 is latest, so I'm currently building 3.8 from source) - but how would you recommend doing this on a user's machine? On Wed, Mar 23, 2016 at 5:17 PM, David Jones <djones at xtreme-eda.com> wrote:

On Wed, Mar 23, 2016 at 5:55 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > If you’re shipping binaries, statically link. That's a good question - should I ship binaries? I've picked up the idea that if you want a Linux program of a version that isn't included in your distro packages, you build from source, but it seems here that including a binary in the

Series of cleanups to autotools build config files to utilize the available xorg-server macros, defaults and more closely match other modern Xorg drivers. Notable improvements: - gitignore fully covers potential build artifacts - Simplify logic given stated minimum required version of xorg-server 1.8 - Remove use of deprecated, outdated or no longer required macros - Utilize xorg macros where

After downloading "celt-0.11.1.tar.gz" to OS X 10.6, I was able to ./configure and make with no problems. However, when I "git clone git://git.xiph.org/celt.git" then cd to celt, there is no file called "configure". So, I just took a guess and ran autogen.sh which then created a "configure" I then ran the new ./configure and saw the following:

Hello, I can compile metadata plugin using debian squeeze + wheezy. But build on suse enterprise server 9,10 and 11 failed. The metadata plugin require autoconf-2.65 which i too new. On the other side I can build the dovecot-2.2.4 and pigeonhole-0.4.0 plugin without problems: dovecot require autoconf-2.59 and pigeonhole does not require any specific autoconf version. I asked the authors of the

Hello all, I found OS X still has one remaining issue in the autotools. OS X does not include pkg-config by default, and whatever mechanism installs it places pkg.m4 in some location among: /opt/local/share/aclocal/pkg.m4 /usr/local/share/aclocal/pkg.m4 PKG_CHECK_MODULES isn't defined if pkg.m4 isn't in /usr/share/aclocal, so ./configure dies without augmenting aclocal's search

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

On 23 Mar 2016, at 17:45, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > When you say 'configuring and installing an appropriate version of LLVM and its libraries yourself' - that is indeed what I did on my own machine (Ubuntu 14.04 apt-get thinks 3.4 is latest, so I'm currently building 3.8 from source) - but how would you recommend doing this on a

On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote: > > running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: > + autoreconf -i > configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- Notes: This is the simplest solution suggested to me by Rich and it works. Most of autotools are not friends with me, so the other approach I tried, with requiring at least OCaml 4.05.0, having this fix in only for OCaml < 4.06.0 and properly detecting and reporting that, was a bit ugly. You can see

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at outlook.com> wrote: > Hi Mark, > > Thanks for the feedback. > > By default CMake is building the static library in debug, to get other > things one has to explicit turn it on. > > Hi, By default CMake uses the "empty" build, which is used in combination with the environment variables CFLAGS and

With recent bug fixes and performance tunings, AutoFDO at llvm has reached a usable state. To evaluate performance, we used O3/-fprofile-use/-fprofile-sample-use respectively to optimize clang itself, and measure its speed. clang built with -fprofile-use is ~20% faster than clang built with O3 clang built with -fprofile-sample-use is ~10% faster than clang built with O3 AutoFDO can deliver 50%

Diego, I noticed yesterday that your attributes.m4 autoconf macro package, part of the autotools build support you contributed to opusfile, is licensed GPL, rather than the usual blanket grant for macros. Are you willing to relicense this so it's compatible with the project's overall BSD license? -r

Hi All, Our team at Facebook is building a new context-sensitive Sample PGO as an alternative to the existing AutoFDO. We’d like to share our motivation, propose a new design, and reveal preliminary results on benchmarks. We will refer to the proposed design as CSSPGO in this RFC. The new CSSPGO leverages simultaneous LBR and stack sampling to construct a full context-sensitive profile. It

This patch series modernizes various aspects of the autotools based build system. There is a lot more that could and should be done, but I tried to stay conservative for now and just resolve some of the most obvious issues. Max Horn (5): configure: replace XIPH_C_FIND_ENDIAN by AC_C_BIGENDIAN autogen.sh: replace this by a simple call to autoreconf configure: always print

See my answers inline. From: Xinliang David Li <davidxl at google.com> Date: Friday, August 7, 2020 at 7:57 PM To: Wenlei He <wenlei at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi <wmi at google.com>, Hongtao Yu <hoy at fb.com> Subject: Re: [RFC] Context-sensitive Sample PGO with Pseudo-Instrumentation On Fri, Aug 7,