similar to: [LLVMdev] [PATCH] llvm-config: Add support for LIBDIR_SUFFIX.

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

Hi, here is a patch for fixing the libdir suffix issue in llvm-config on CMake builds (if using -DLLVM_LIBDIR_SUFFIX=32/64). It works successfully on my openSUSE i586 (/usr/lib/) and x86_64 (/usr/lib64/) systems. Please CC me on further discussion. Thanks. Johannes -------------- next part -------------- A non-text attachment was scrubbed... Name:

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

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,

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

Hi, I am trying to install llvm 2.5 in my PowerPC machine. I have already installed XCode Tools 2.4.1. I can compile programs using gcc run them. I try to configure llvm 2.5, the configuration aborts with following message: checking build system type... powerpc-apple-darwin8.11.0 checking host system type... powerpc-apple-darwin8.11.0 checking target system type... powerpc-apple-darwin8.11.0

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

> > *hi,Óscar:* > * * > >Why? Please describe a case. > > >I need to do some futher experiment and to see whether I have been > wrong. > Since I touch this problem several months ago, so I did some test using the 3.2svn, the reason why uninstalled build 'cmake not work lies in set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) set(LLVM_INCLUDE_DIRS

*1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build directory, recursively, and all the output is what I pasted in last email (just the same to the that in source directory). Maybe the configure failed to do it. My command list for building the test suit is as followings:* *(1) cd ~/SRC_DIR/llvm/projects* *(2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk

Hi! I'm porting my own projects to CMake (seems very cool) and I want to import LLVM as external libraries. To simplify this CMake supports an export feature that can export an LLVM.cmake file that lists all libraries of LLVM. With this I could simplify the use of LLVM in my own CMake project. For this the following cmake files of LLVM have to be extended (patches are provided at the end of

Hi, Following on from another thread (Long-Term Support for LLVM Projects Extension to Build System) I'd like to discuss the testing of the exported LLVM CMake targets which can be used by consumers of LLVM as documented in [1]. Right now we don't test this feature **at all** and as a result it has been or is * broken in trunk * broken by those packaging LLVM * broken in the official

hume npx <humeafo at gmail.com> writes: Sorry for commenting the bug report here, but I can't loging to bugzilla right now. > Using cmake should be the right thing if you'd like to support windows, but > it seems that no enough effort on this build system, eg > http://llvm.org/bugs/show_bug.cgi?id=12157 three months passed, There is indeed a problem with the value

*hi,Óscar:* * * *so following patch should address both the relocation problem and uninstall tree problem, not fully tested just for discussion.* * * Index: LLVMConfig.cmake.in =================================================================== --- LLVMConfig.cmake.in (revision 159425) +++ LLVMConfig.cmake.in (working copy) @@ -32,8 +32,11 @@ set(LLVM_ON_WIN32 @LLVM_ON_WIN32@)

hume npx <humeafo at gmail.com> writes: > Hi, Óscar: > nice to hear some voice on this. about LLVM_TOOLS_BINARY_DIR, yes, it > made the installed version work only, if you'd like the uninstalled version > to work, it should be detected as you suggested. > > about LLVM_INSTALL_PREFIX the purpose is to make it really relocatable, > eg, when installed under

Hi, Óscar: nice to hear some voice on this. about LLVM_TOOLS_BINARY_DIR, yes, it made the installed version work only, if you'd like the uninstalled version to work, it should be detected as you suggested. about LLVM_INSTALL_PREFIX the purpose is to make it really relocatable, eg, when installed under /lib/llvm I just later need to move the installation tree to /lusr/local/lib/llvm

*hi,Óscar:* * * >LLVM_INSTALL_PREFIX is supposed to contain the value of > >CMAKE_INSTALL_PREFIX when you configured LLVM. Using it for setting > >other variables is just a convenience. > > Ok, I understood your point, so I'd like to develop another patch to make > it relocatable and respect the original meanings. > > >CMAKE_CURRENT_LIST_FILE can be

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>