similar to: [LLVMdev] [PATCH] llvm-config: Support LLVM_LIBDIR_SUFFIX on CMake build.

Rather than using sed, it would be better to change the .in to use @...@ variables to expand the libdir suffix along with the other variables expanded when going from llvm-config.in to llvm-config. On Sat, Jul 30, 2011 at 1:32 AM, Johannes Obermayr <johannesobermayr at gmx.de>wrote: > Hi, > > here is a patch for fixing the libdir suffix issue in llvm-config on CMake > builds

--- autoconf/configure.ac | 4 +++- cmake/modules/LLVMConfig.cmake.in | 3 ++- configure | 4 +++- tools/llvm-config/Makefile | 6 ++++++ tools/llvm-config/llvm-config.in.in | 3 ++- 5 files changed, 16 insertions(+), 4 deletions(-) diff --git a/autoconf/configure.ac b/autoconf/configure.ac index f3e94e8..cd943cc 100644 ---

Why? -eric On Sep 20, 2011, at 9:14 AM, Johannes Obermayr wrote: > --- > autoconf/configure.ac | 4 +++- > cmake/modules/LLVMConfig.cmake.in | 3 ++- > configure | 4 +++- > tools/llvm-config/Makefile | 6 ++++++ > tools/llvm-config/llvm-config.in.in | 3 ++- > 5 files changed, 16 insertions(+), 4 deletions(-)

On Tuesday 20 September 2011 11:23:05 Eric Christopher wrote: > Why? > > -eric > Because openSUSE and many other linux distributions put all things to /usr/lib (i586) and /usr/lib64 (x86_64) or /usr/lib32. So it is possible to install x86 and x86_64 versions at the same time ... (See also http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/042068.html and

On Tuesday 20 September 2011 11:50:07 Eric Christopher wrote: > > On Sep 20, 2011, at 11:46 AM, Johannes Obermayr wrote: > > > On Tuesday 20 September 2011 11:23:05 Eric Christopher wrote: > >> Why? > >> > >> -eric > >> > > > > Because openSUSE and many other linux distributions put all things to /usr/lib (i586) and /usr/lib64

On Sep 20, 2011, at 11:46 AM, Johannes Obermayr wrote: > On Tuesday 20 September 2011 11:23:05 Eric Christopher wrote: >> Why? >> >> -eric >> > > Because openSUSE and many other linux distributions put all things to /usr/lib (i586) and /usr/lib64 (x86_64) or /usr/lib32. > So it is possible to install x86 and x86_64 versions at the same time ... > (See

Hello Anton Thu, 3 Aug 2006 12:38:54 +0400 you wrote: > I've updated it yesterday and rebuilt - llvm built fine. But when > building llvm-gcc4 (also updated yesterday from new /trunk > directory) it fails with the same error. You might easily get llvm-gcc4-mingw32 binaries from "prerelease" directory. Since stdcall, fastcall & dllimport stuff is unsupported right now,

Hi, Apparently there are two bugs in tools/llvmc/c: /.../llvm/tools/llvmc/c:12: Error: Invalid top level configuration item /.../llvm/tools/llvmc/c:28: Error: Expecting a program name /.../llvm/tools/llvmc/c had 2 errors. Terminating. The first error relates to the following line(s): lang.libs=%llvmgccdir%/lib %llvmgccdir%/lib \ %llvmgccdir%/lib/gcc/%llvmgccarch% ... the other one to:

Hello, I'm trying to setup dovecot-antispam, and even though the configuration and the installation seem to have gone well, dovecot is telling me it's not finding it. Here is the symptom: schmitta at top-wifi ~> /usr/local/Cellar/dovecot/2.2.10/libexec/dovecot/imap -c ~/.dovecotzimbra.rc Fatal: Plugin 'antispam' not found from directory

Moving to llvm-dev (I think this has gone a bit further than a patch review discussion) In hindsight I probably should have explained more of my thinking on this with the patch, or done an RFC on llvm-dev to start with. I’l do that now, and answer the questions along the way. I sent a separate email discussing Justin’s patch review feedback. In the build system today there is no strong

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 18 Feb 2014, Alan Schmitt wrote: > I'm trying to setup dovecot-antispam, and even though the configuration > and the installation seem to have gone well, dovecot is telling me it's > not finding it. > > schmitta at top-wifi ~> /usr/local/Cellar/dovecot/2.2.10/libexec/dovecot/imap -c ~/.dovecotzimbra.rc > Fatal:

On Sun, 2006-08-13 at 21:18 +0200, Bram Adams wrote: > Hi, > > Apparently there are two bugs in tools/llvmc/c: This tool is, as yet, unfinished. > > /.../llvm/tools/llvmc/c:12: Error: Invalid top level configuration item > /.../llvm/tools/llvmc/c:28: Error: Expecting a program name > /.../llvm/tools/llvmc/c had 2 errors. Terminating. > > The first error relates to

I suspect the answer is "no" as it dies with a hard error for me. I don't want to fix this if it isn't being used; I would rather delete it and avoid the complexity it brings. Thoughts? This came up because I have changes to LLD's CMake build to support LLVM_LIBDIR_SUFFIX more effectively, but I can't test them in a standalone build. -Chandler -------------- next part

The behavior of automatically detecting libraries installed in the same prefix feels like magic to me anyway. Perhaps it would be better to have project-level variables for specifying the path to them individually? The default value for them could remain as origin/../lib which would keep from breaking things. On Thu May 29 2014 at 7:06:17 PM, Chandler Carruth <chandlerc at google.com>

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++

Hi, Op 14-aug-06, om 09:29 heeft Reid Spencer het volgende geschreven: > >> Apparently, %llvmgccdir% and %llvmcc1% are not recognized as a useful >> variable by the llvmc configuration parser. > > Actually, they are. See tools/llvmc/ConfigurationDriver.cpp around > line > 304. Also, they are recognized by the lexer. Its more likely that when > you configured LLVM

> > If you're building llvm-gcc4, you don't need the runtime libraries, so > I'd just stick with the "tools-only" build and declare success. If > you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :) I switched to llvm-gcc4 but when I run make from obj folder i run into folowing errors: Can't find a library with no dependencies at

https://bugs.freedesktop.org/show_bug.cgi?id=39530 Summary: Also after installing Obermayrs drm-nouveau driver booting succeeds only with nomodeset Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component:

That's great. For multi targets compilerrt-rts, in old llvm 3.5 configuremakefileconfigure/makefile system, it will build multiple libs for each target on the target list pass to clang building. but since you said compiler-rt now require sysroot for proper headers, then I don't think multi libs can be built together any more. However, according to my knowledge, without compiler-rt, a

Hi, Trying to compile llvm with the following configuration on Linux x86-64: cmake -G Ninja -DBUILD_SHARED_LIBS=ON \ -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold" \ -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold"\ -DCMAKE_BUILD_TYPE=RelWithDebInfo ' \ -DCMAKE_C_FLAGS="-O2 -g" \