similar to: LLVM's use of rpath on macOS

I'm looking at an issue for Homebrew (OS X package manager) where the compiled libc++ tries to load libc++abi at "@rpath/libc++abi.1.dylib", resulting in a dyld error. The issue can be found at https://github.com/Homebrew/homebrew/issues/47149 From what I can tell, this is a result of lines 561-564 of the CMakeLists.txt in the main LLVM repo: set(CMAKE_BUILD_WITH_INSTALL_RPATH ON)

This way, an LLVM compiled after setting GCC_INSTALL_PREFIX will work correctly if you don't want to install LLVM into the GCC_INSTALL_PREFIX. --- CMakeLists.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 9ec3e33..c85a028 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -450,7 +450,12 @@ if (APPLE)

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>

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake

> Are you using cmake for building LLVM? > > If the answer is yes, please ask on the cmake mailing list. > > Usually cmake sets the RPATH when building LLVM as shared objects. But > on my Linux box it does not set RPATH when building LLVM as static > libraries. I do not have cmake installed - and when packaging for NetBSD (IIRC) you need to explicitly tell it that cmake is

Hello LLVM devs, I am trying to package llvm for NetBSD. The package checker scripts are complaining about bad rpaths in the binaries. I see that they are relative to the build directory. I have no idea why that would be. Can you explain? If I build as myself, for testing (e.g.): $ readelf -d ~/downloads/llvm-2.6/Release/bin/llvm-ar Dynamic section at offset 0x15af28 contains 25 entries:

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that

When compiling in Ubuntu 6.06 64 bit using this guide: http://wiki.winehq.org/WineOn64bit When I do 'sudo make install' I get this error: make[2]: Entering directory `/home/marcus/wine/dlls/gdi' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o

Hey Michael, I completely agree that setting the rpath properly the first time around is much preferred. But, changes to the binary, particularly during development is much quicker. Prebuilt libraries which are being repackaged is one use case that is missed. In the past, I’ve even used it to repair am incorrectly built library which was missing the library name. There are a few different

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is

Is anyone else seeing this bootstrap failure on current svn trunk? [ 6%] Linking CXX executable ../../bin/llvm-tblgen cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen && /sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt --verbose=1 /sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Werror=date-time

if i run autogen.sh on fresh 1.1.beta9 source, it fails @ ./autogen.sh ... 100%[====================================>] 154,427 115.09K/s 08:45:56 (114.82 KB/s) - `wiki-export.tar.gz' saved [154427/154427] configure.in:16: required file `./config.rpath' not found configure.in:5: installing `./missing' configure.in:5: installing `./install-sh'

first off im running on an AMD64 3800+, Ubuntu 6.06, 2.6.15-25-amd64-generic ive been working on getting this thing to work for the past few hours, setup symbolic links like in the howto run wine on amd64 tutorial, plus some. and started compiling, make depend went well, and so was make all until this happened make[2]: Entering directory `/home/anolis/Desktop/wine-0.9.16/dlls/gdi'

We try to change cmake's behaviour so that it uses $ORIGIN in the rpath, making the binaries relocatable. That might be falling in here for some reason. Sent from my iPhone > On Feb 12, 2014, at 11:07, Brad King <brad.king at kitware.com> wrote: > >> On 02/12/2014 08:08 AM, Mathias Bauer wrote: >> Hi dear list, >> >> I tried to build llvm+clang on an

On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>

"Larson, Timothy E." <TELarson at west.com> writes: > Hello LLVM devs, > > I am trying to package llvm for NetBSD. The package checker scripts > are complaining about bad rpaths in the binaries. I see that they are > relative to the build directory. I have no idea why that would be. > Can you explain? Are you using cmake for building LLVM? If the answer is

I'd like to contribute xapian to fedora extras. It builds OK, but breaks one requirement for inclusion. I need to disable rpath. Unfortunately, I'm not very familiar with the autoconf, automake,... setup, and I can't seem to find where to disable this. I tried autoreconf, but that didn't fix it. Can anyone help me?

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After