similar to: [LLVMdev] rpaths in llvm binaries

"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

> 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

Marcus, Thanks for the spec file. I'm fairly new to creating RPM's and I just found out that the issue is taking place during the 'make check' portion of the spec file. I'm not sure what 'make check' does after having googled it, although, I think it checks for run-time errors. Any hints? Eric On 5/16/2015 12:52 PM, Marcus Rueckert wrote: > On 2015-05-16 11:52:55

Hi all, I'm trying to understand why LLVM uses @rpath as the install name in its dynamic libraries on macOS. This complicates the process of linking against libLLVM from third-party tools and isn't nearly as common a practice on macOS as it is on Linux. I tried tracing through history on the LLVM repo and the main thing I could find was a commit from ages ago saying that the libraries are

I'm running on Sun Blade 2500 with a GeForce 8400 GS PCI. After (maybe?) fixing a few errrors with bo allocation, I'm getting a lot of IB_EMPTY errors, ultimately resulting in a GPU lockup. I don't have any sort of framebuffer visible. After reading dma-pusher.txt, I see "An attempt to submit IB entry with length zero will raise DMA_PUSHER error of type IB_EMPTY." How would

> On October 21, 2016 at 6:27 AM Tamsy <dovecot-list at mohtex.net> wrote: > > > Timo Sirainen wrote on 20.10.2016 04:01: > > http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz > > http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz.sig > > > > There are quite a lot of changes since v2.2.25. Please try out this RC so we can get a good

Hello! I noticed that the binaries of all llvm tools contain an rpath to $OBJDIR/Release/bin. I just only learned about rpaths, but the way I understand them this would only make sense if that path would contain shared libraries, which it doesn't. Especially it makes no sense if I install the binaries and delete the build directory (where it potentially even leaves a security issue behind).

The headers hadn't been regenerated in a long time and had seen a number of manual modifications. A few changes: - remove nvc0_2d entirely, use the nv50 header which has the nvc0 values too - remove 3ddefs, it's identical to the nv50 file - move macros out into a separate file Also the upstream rnndb changed the overall chip naming convention; this was fixed up manually in the

Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- I haven't pushed these changes to renouveau.xml yet, I'll do it soon if you guys are OK with this. nouveau/nouveau_class.h | 1036 +++++++++++++++++++++++----------------------- 1 files changed, 518 insertions(+), 518 deletions(-) diff --git a/nouveau/nouveau_class.h b/nouveau/nouveau_class.h index c5fe5d7..87e167b

Hi All, I'm looking to package up celt for inclusion in Fedora as the next stable release of ekiga/opal will have support for it. I've run into two issues in compiling it into a rpm. The first is a show stopper, then second one not so much of an issue but thought I'd report it for reference. The first issue is due to the celtdec and celtenc explicitly define rpath. I get the

These are copied directly from the mesa repository. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/hwdefs/gm107_texture.xml.h | 365 +++++++++++++++++ src/hwdefs/nvc0_3d.xml.h | 867 +++++++++++++++++++++++++---------------- 2 files changed, 892 insertions(+), 340 deletions(-) create mode 100644 src/hwdefs/gm107_texture.xml.h diff --git

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'

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)

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>

Here's a patch series to make libguestfs use gnulib via a git submodule. The first thing I did was to look at the failures from "make syntax-check" and fix the config.h-related ones below. The others are now temporarily disabled via a variable in cfg.mk. I fixed the config-h problems and moved those change sets to precede the test-adding one, so that bisection still works, even if

The headers hadn't been regenerated in a long time, and there were a few minor divergences. Among other things, rnndb has changed naming to G80/etc, for now I've not tackled switching that over and manually replaced the nvidia codenames back to the chip ids. However no other modifications of the headergen'd headers was done. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>

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?

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)

Hello all, I am sad to say that I am no longer working for rPath, Inc. They have, of course, been extremely supportive of all my upstream work, including Syslinux, but have decided that given the economic climate they could no longer afford to keep me on staff. It does mean that while I still haven't figured out what to do next, I am available to do short-term contracts if there is any

Whilst cleaning up the lintian reports in preparation for the Debian/Ubuntu hivex package one of the issues is: E: libhivex-perl: binary-or-shlib-defines-rpath ./usr/lib/perl/5.10.1/auto/Win/Hivex/Hivex.so /tmp/buildd/hivex-1.2.1/perl/../lib/.libs I've temporarily dealt with this by using chrpath in the build and a rule to delete the RPATH from "auto/Win/Hivex/Hivex.so". I wonder