search for: rpaths

On Sun, Jul 19, 2015 at 8:32 AM, Dimitry Andric <dimitry at andric.com> wrote: > On 19 Jul 2015, at 01:44, Dimitry Andric <dimitry at andric.com> wrote: > ... >> Hm, strangely enough, this version of the script does not go further than the Phase 2 installation, and does not run any tests? This used to work fine for the release_36 branch. >> >> I think it is

...building the packages: celt.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/celtdec ['/usr/lib64'] celt.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/celtenc ['/usr/lib64'] ******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild' * to fail. To ignore these errors, you can set the '$QA_RPATHS' * environment variable which is a bitmask allowing the values * below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standa...

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: Tag Type...

I was attempting to rebuild the Centos 5.4 freetype rpm freetype-2.2.1-21.el5_3.src.rpm and got the following error. What do I need to do to solve it? ERROR 0001: file '/usr/bin/ftvalid' contains a standard rpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/fttimer' contains a standard rpath '/usr/lib64' in [/usr/lib64:/usr/lib] ERROR 0001: file

...nking 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 now relocatable. While that's indeed true, rpaths put a burden on all consumers of the library (who now need to pass special flags to their linker) and unless there's a pressing need for them, most libraries avoid the practice. Indeed, the use of @rpath in LLVM seems to have been a bit confusing and has undergone dozens of changes over time, w...

> 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

Hi dear list, I tried to build llvm+clang on an OpenSuse BuildServer for ARM. The build was carried out with CMake 2.8.11. In the installation step I got the following error: > [26815s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/llvm-3.4.99-336.1.arm/usr/lib/libLLVMSupport.so > [26815s] CMake Error at lib/Support/cmake_install.cmake:45 (FILE): > [26815s] file RPATH_CHANGE could

/usr/bin/ld: bad -rpath option collect2: ld returned 1 exit status make[4]: *** [libFLAC.la] Error 1 --- flac-1.1.2/src/libFLAC/Makefile.in.orig 2005-02-04 21:23:37.000000000 -0500 +++ flac-1.1.2/src/libFLAC/Makefile.in 2006-04-30 20:30:00.000000000 -0400 @@ -399,7 +399,7 @@ rm -f "$${dir}/so_locations"; \ done libFLAC.la: $(libFLAC_la_OBJECTS)

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

Resolve in the guest the given path, so absolute symlinks can be listed using appliance tools without resolution errors. Also remove the note about the possibility to escape the sysroot using ll and llz, since realpath won't return paths outside sysroot. Fixes part of RHBZ#1293276. --- daemon/ls.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git

> that CMake is trying to update the installed binary file's > RPATH to contain the $ORIGIN/../lib value. It complains > that no RPATH field at all is found in the file. The linker > may be dropping it for some reason, which is why I asked > Mathias to try: Btw, an awesome way to fix this would be to set rpath to $ORIGIN/../lib during the link itself. That way it doesn't

"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 yes, please ask on the cmake mailing list. Usually cmake sets the RPATH when building LLVM as shared object...

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'

On 19 Jul 2015, at 00:17, Dimitry Andric <dimitry at andric.com> wrote: > > On 17 Jul 2015, at 01:09, Hans Wennborg <hans at chromium.org> wrote: >> >> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com> wrote: >>> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote: >>>> >>>> Dear

gccld passes -shared through if it's generating a shared library, but if you're compiling a program that needs to have its symbols externally accessible, it doesn't pass -export-dynamic through to gcc for the final link. The attached patch fixes this. I've tested with a small test case I sent Chris, and with Python; both seem to work. I also fixed some inaccurate comments in

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)

Building flac git head on OS/2 dies when running "sh /usr/bin/autoreconf --install --force" ... configure.ac:32: installing './compile' configure.ac:35: installing './config.guess' configure.ac:344: error: required file './config.rpath' not found configure.ac:35: installing './config.sub' configure.ac:26: installing './install-sh' configure.ac:26:

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

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>

Hello, I encountered errors when building rpm on fedora33: Versions: libvirt: v6.9.0-rc2 gcc-10.2.1-5.fc33.x86_64 meson-0.55.3-1.fc33.noarch ninja-build-1.10.1-2.fc33.x86_64 binutils-2.35-11.fc33.x86_64 Steps: 1. Archive libvirt source code to ~/rpmbuild/SOURCES/libvirt-6.9.0.tar.xz 2. Copy libvirt.spec.in to ~/rpmbuild/SPECS/libvirt.spec. Then `sed -i s/@VERSION@/6.9.0/g