Re: [Nix-dev] Why not use SONAME instead of RPATH
This woild be fantastic. TBH I've been wondering the same thing when reading documentation talked > about rpath. This seems like the simpler more direct method. It also > avoid the theoretical problem where there are two libraries of the same > name in different folders, this allows you to specify exactly which one > although that is unlikely to ever become a real problem. > I just want to point out that for us this problem is not theoretical. We regularly have binaries in /nix/store segfault or produce other errors due to bad interactions with LD_LIBRARY_PATH on shared RHEL and Ubuntu machines. I filed this as an issue here: https://github.com/NixOS/nix/issues/902#issuecomment-219389037 But I'm closing it now because it seems like a known implication of the design that LD_LIBRARY_PATH clobbers nix-built executables. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
That's too bad about dlopen, but it's good to see that things are well thought through. :) "soname" is only in version patchelf-0.9. The manpage reads as follows. --print-soname Prints DT_SONAME entry of .dynamic section. Raises an error if DT_SONAME doesn't exist. --set-soname SONAME Sets DT_SONAME entry of a library to SONAME. Cheers Silvio ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
On 04/29/2016 12:02 AM, Thomas Tuegel wrote: > patchelf can do this, but only for shared libraries that are actually > linked. Really? I can't see anything like that in the man pages. --Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
On Thu, Apr 28, 2016 at 1:45 PM, Vladimír Čunát wrote: > On 04/28/2016 08:20 PM, Александр Цамутали wrote: >> Is it possible to apply this approach to binary packages? > > I don't think so, but that doesn't seem really relevant. The suggestion > is to change what our compiler produces... patchelf can do this, but only for shared libraries that are actually linked. RPATH has the advantage of affecting dlopen() calls, too. It makes me sad that I know this. :-( Regards, Tom ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
On 04/28/2016 08:20 PM, Александр Цамутали wrote: > Is it possible to apply this approach to binary packages? I don't think so, but that doesn't seem really relevant. The suggestion is to change what our compiler produces... --Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
Is it possible to apply this approach to binary packages? -- Александр Цамутали ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
Woah I love that! +1, I don't see why we can't do that… Wout. On Wed, Apr 20, 2016 at 1:52 PM Silvio Frischknecht wrote: > Hello, > > I recently found out that if you set the SONAME of a library to an > absolute path. > > gcc --shared -Wl,-soname="$(pwd)/libxyz.so" -o libxyz.so libxyz.c > > and then later link to it > > gcc main.c -L. -lxyz > > the dynamic linker will only look for the library in the exact path > specified when compiling the library. > > Advantages over RPATH: > + probably faster since rpaths in nixos tend to be quite long and every > library has to be looked for in every folder (linear vs quadratic > complexity) > + only has to be setup once per library - all referrers will > automatically work correctly > > In this case the path can't be overwritten by LD_LIBRARY_PATH. I guess > that could be an advantage or a disadvantage depending on how you look > at it. > > Cheers > > Silvio > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Wout. (typed on mobile, excuse terseness) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why not use SONAME instead of RPATH
On 17/04/16 12:02, Silvio Frischknecht wrote: > > Advantages over RPATH: > + probably faster since rpaths in nixos tend to be quite long and every > library has to be looked for in every folder (linear vs quadratic > complexity) > + only has to be setup once per library - all referrers will > automatically work correctly > TBH I've been wondering the same thing when reading documentation talked about rpath. This seems like the simpler more direct method. It also avoid the theoretical problem where there are two libraries of the same name in different folders, this allows you to specify exactly which one although that is unlikely to ever become a real problem. But in general in my Nix usage I try to avoid long search paths such as rpath and PATH, instead preferring to use absolute paths everywhere with no search just because it is simpler, and probably more performant. Cheers, Kevin signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Why not use SONAME instead of RPATH
Hello, I recently found out that if you set the SONAME of a library to an absolute path. gcc --shared -Wl,-soname="$(pwd)/libxyz.so" -o libxyz.so libxyz.c and then later link to it gcc main.c -L. -lxyz the dynamic linker will only look for the library in the exact path specified when compiling the library. Advantages over RPATH: + probably faster since rpaths in nixos tend to be quite long and every library has to be looked for in every folder (linear vs quadratic complexity) + only has to be setup once per library - all referrers will automatically work correctly In this case the path can't be overwritten by LD_LIBRARY_PATH. I guess that could be an advantage or a disadvantage depending on how you look at it. Cheers Silvio ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
