search for: chrpath

On 07/30/2014 10:06 AM, Larry Evans wrote: > On 07/30/2014 12:35 AM, Ben Pope wrote: >> On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: >> >>> ldd your_built_clang | grep libstdc++ >>> chrpath -l your_built_clang >> >> Hmm, where "your_built_clang" should be the actual failing executable: >> /home/evansl/dwnlds/llvm/3.5rc1/build/Release+Asserts/bin/llvm-tblgen >> >> Ben > Here's the result: > > -*- mode: compilation; default-directory...

On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: > ldd your_built_clang | grep libstdc++ > chrpath -l your_built_clang Hmm, where "your_built_clang" should be the actual failing executable: /home/evansl/dwnlds/llvm/3.5rc1/build/Release+Asserts/bin/llvm-tblgen Ben

...n RPATH: > > $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH > RPATH > $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin To avoid such behavior [1] , in Debian and Ubuntu packages, I am doing: chrpath -d $(TARGET_BUILD)/Release/bin/clang chrpath -d `find $(CURDIR)/debian/tmp/usr/lib/llvm-$(LLVM_VERSION)/bin/ -type f -executable` Sylvestre [1] http://wiki.debian.org/RpathIssue

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

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 if this is an oversight since it is non-portable and refers to a build-time location? There are some helpful notes about this at: http://wiki.debian.org/RpathIssue

Aki Tuomi wrote: >>>> ldd /usr/local/Dovecot-2.2.25/lib/dovecot/libdcrypt_openssl.so >>>> linux-gate.so.1 => (0x00dca000) >>>> libcrypto.so.1.0.0 => not found >>>> ... > > Well, then it leaves only option of using /etc/ld.so.conf > so basically add your libssl location there. You can also affect where shared

It's probably PR12517. Looking at the clang binary, it's got a /home/ dir in RPATH: $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH RPATH $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin This will slow things down if the system tries to automount /home/aadgrand. Maybe we should merge r182559

Hi Rich, I meet below thing, [root at gaowanlong libguestfs]# virt-sysprep --help virt-sysprep: error while loading shared libraries: libguestfs.so.0: cannot open shared object file: No such file or directory [root at gaowanlong libguestfs]# ln -s /usr/local/lib/libguestfs.so.0 /usr/lib64/libguestfs.so.0 [root at gaowanlong libguestfs]# virt-sysprep --help virt-sysprep: reset or unconfigure a

> But I'm very much against allowing any sort of option that specifies full > paths to be embedded, including "-L". Typically, object files are > location-independent -- if you want to copy them to another system and run > the linker there (with an appropriate sysroot path), that's going to work > perfectly fine. But as soon as you start allowing path options to be