I'm packaging a tool that includes some shared objects natively, and I think the right approach to add those objects to the rpath is to use the addAutoPatchelfSearchPath function to the installPhase of my Nix expression, but it's not picking up the .so libs as expected. I've tried setting the search path explicitly, relatively, etc. What would the correct usage be?

installPhase = ''
    mkdir -p $out
    addAutoPatchelfSearchPath $(pwd)
    cp -r $src $out
''

What's the difference between running a program with ld + --library-path and with changing the loader with patchelf? To illustrate, here is a binary that wouldn't run as is, presumably because of lack of recent versions of libraries: $ ~/DOWNLOADS/APPS/magick /tmp/.mount_magickXiWzgy/usr/bin/magick: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_magickXiWzgy/usr/lib/libMagickCore-7.Q16HDRI.so.10) /tmp/.mount_magickXiWzgy/usr/bin/magick: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /tmp/.mount_magickXiWzgy/usr/lib/libMagickCore-7.Q16HDRI.so.10) /tmp/.mount_magickXiWzgy/usr/bin/magick: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_magickXiWzgy/usr/lib/liblcms2.so.2) ... $ I tried to run it with 3 other loaders and library paths, (core18, core20 and core22). Got ELF file ABI version invalid each time. $ /snap/core18/current/lib64/ld-linux-x86-64.so.2 --library-path /snap/core18/current/usr/lib/x86_64-linux-gnu/ ~/DOWNLOADS/APPS/magick /home/ychaouche/DOWNLOADS/APPS/magick: error while loading shared libraries: /home/ychaouche/DOWNLOADS/APPS/magick: ELF file ABI version invalid $ /snap/core20/current/lib64/ld-linux-x86-64.so.2 --library-path /snap/core20/current/usr/lib/x86_64-linux-gnu/ ~/DOWNLOADS/APPS/magick /home/ychaouche/DOWNLOADS/APPS/magick: error while loading shared libraries: /home/ychaouche/DOWNLOADS/APPS/magick: ELF file ABI version invalid $ /snap/core22/current/lib64/ld-linux-x86-64.so.2 --library-path /snap/core22/current/usr/lib/x86_64-linux-gnu/ ~/DOWNLOADS/APPS/magick /home/ychaouche/DOWNLOADS/APPS/magick: error while loading shared libraries: /home/ychaouche/DOWNLOADS/APPS/magick: ELF file ABI version invalid $ Then got a Segmentation fault when I tried to run it after changing the loader and the rpath directly in the binary with patchelf, like so: $ patchelf --set-interpreter /snap/core18/current/lib64/ld-linux-x86-64.so.2 --set-rpath /snap/core18/current/usr/lib/x86_64-linux-gnu/ magick $ ./magick Segmentation fault $ ldd magick not a dynamic executable $ even ldd fails to recognize it as a dynamic executable, although readelf can read it. here's output of ldd as requested by @user10489 $ file DOWNLOADS/APPS/magick DOWNLOADS/APPS/magick: ELF 64-bit LSB executable, x86-64, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=9fdbc145689e0fb79cb7291203431012ae8e1911, stripped $ My question is why do I have ELF file ABI version invalid when specifying the loader from the command line, and a segmentation fault when changing the loader (and rpath) inside the binary?

I am trying to run Qt Design Studio 2.3.1 Community on NixOS. **My nix derivation code:** flake.nix:

{
  description = "Qt Design Studio";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system: 
    let
      pname = "qtdesignstudio";
      version = "v2.3.1";

      pkgs = import nixpkgs { inherit system; config.pulseaudio=true;};

    in { 
        packages.default = pkgs.qt6Packages.callPackage ./. {inherit pname version; };
    }
  );
}

default.nix:

{ pname, version, stdenv, pkgs, qtbase, wrapQtAppsHook, qt5compat, qtpositioning, qtserialport }: 

let
   zip_name = "qtdesignstudio-2.3.1.zip";
in
stdenv.mkDerivation {
  
  inherit pname version; 

  src = ./.;

  buildInputs = with pkgs; [

    gcc-unwrapped
    cairo
    pango
    gtk3
    atk
    gdk-pixbuf
    pulseaudio
    alsa-lib

    gst_all_1.gstreamer
    gst_all_1.gst-plugins-base
    gst_all_1.gst-plugins-bad

    xorg.libxkbfile
    xorg.libxshmfence

    nss_latest
    mysql80

  ] ++ [ 

    qt5compat
    qtbase
    qtpositioning
    qtserialport 

  ];

  unpackPhase = "true";

  nativeBuildInputs = with pkgs; [ 
    autoPatchelfHook 
    unzip
  ] ++ 
  [ wrapQtAppsHook ]; 

  installPhase = ''
    mkdir -p $out
    unzip $src/${zip_name} -d $out
  '';

}

However while building it, I get the following error:

...
 > auto-patchelf: 1 dependencies could not be satisfied
       > error: auto-patchelf could not satisfy dependency libQt5SerialPort.so.5 wanted by /nix/store/bih1ngcz4h0w01i875iys83lcfjksp2m-qtdesignstudio-v2.3.1/qt5_design_studio_reduced_version/plugins/position/libqtposition_serialnmea.so
       > auto-patchelf failed to find all the required dependencies.
...

is there anyway to resolve it? I tried [this answer](https://discourse.nixos.org/t/qt-development-environment-on-a-flake-system/23707/3) from NixOS discourse but it is for Qt5, not for Qt6. Would be great if you could help me as I am totally stuck on it.

I see that there are other questions like this out there, but the answers there did not work for me. I am using I downloaded the Julia 1.9.2 (Linux, x86-64, glibc) prebuilt binary and tried to execute the binary, but I get the following error.

: ./julia: cannot execute: required file not found

I am able to execute all other binaries on my machine. My understanding is that this is because bash cannot find the interpreter required for executing this file. In this case it should be a loader, I guess? Here's the output of file,

$ file julia
julia: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, with debug_info, not stripped

and ldd

$ ldd julia
	linux-vdso.so.1 (0x00007ffdae587000)
	libdl.so.2 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libdl.so.2 (0x00007fe5955f4000)
	libpthread.so.0 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libpthread.so.0 (0x00007fe5955ef000)
	libc.so.6 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6 (0x00007fe595409000)
	libjulia.so.1 => /home/chaitanyak/Downloads/julia-1.9.2/bin/./../lib/libjulia.so.1 (0x00007fe5953e6000)
	/lib64/ld-linux-x86-64.so.2 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007fe5955fb000)

I am using NixOS 23.05.2573.61676e4dcfee (Stoat) x86_64. Verbose output of ldd

$ ldd -v julia
	linux-vdso.so.1 (0x00007ffcd2942000)
	libdl.so.2 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libdl.so.2 (0x00007efd29f12000)
	libpthread.so.0 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libpthread.so.0 (0x00007efd29f0d000)
	libc.so.6 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6 (0x00007efd29d27000)
	libjulia.so.1 => /home/chaitanyak/Downloads/julia-1.9.2/bin/./../lib/libjulia.so.1 (0x00007efd29d04000)
	/lib64/ld-linux-x86-64.so.2 => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007efd29f19000)

	Version information:
	./julia:
		libc.so.6 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
	/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libdl.so.2:
		libc.so.6 (GLIBC_ABI_DT_RELR) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
	/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libpthread.so.0:
		libc.so.6 (GLIBC_ABI_DT_RELR) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
	/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib64/ld-linux-x86-64.so.2
	/home/chaitanyak/Downloads/julia-1.9.2/bin/./../lib/libjulia.so.1:
		libdl.so.2 (GLIBC_2.3.3) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libdl.so.2
		libdl.so.2 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libdl.so.2
		libpthread.so.0 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libpthread.so.0
		libc.so.6 (GLIBC_2.2.5) => /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6

# Edit I also tried using the possible interpreters directly.

$ /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 julia 
julia: error while loading shared libraries: julia: cannot open shared object file: No such file or directory

$ /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/ld-linux-x86-64.so.2 julia 
julia: error while loading shared libraries: julia: cannot open shared object file: No such file or directory

So, it looks like that it cannot open some .so file, but does not provide its name. ## Edit 2 I ran the interpreters under gdb and it gives some more information.

(gdb) r Downloads/julia-1.9.2/bin/julia
Starting program: /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/ld-linux-x86-64.so.2 Downloads/julia-1.9.2/bin/julia
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libthread_db.so.1".
[Detaching after fork from child process 29527]
[New Thread 0x7ffff17ff6c0 (LWP 29528)]
ERROR: could not load library "/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/../lib/julia/sys.so"
/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/../lib/julia/sys.so: cannot open shared object file: No such file or directory
[Thread 0x7ffff7dae0c0 (LWP 29524) exited]
[Thread 0x7ffff17ff6c0 (LWP 29528) exited]
[New process 29524]
[Inferior 1 (process 29524) exited with code 01]
(gdb)

So, it seems that it is trying to locate sys.so that ships with Julia inside the nix store. So, is this a nix-specific problem? Is the only workaround to create a nix package for Julia 1.9? # Edit 3 So, Julia ships with its own shared object files, and instead of searching for them there, the binary tries to search for them relative to some other location in my nix store. Is modifying RPATH of the julia binary using patchelf a solution to this?

I am patching several libraries on my development server to remove unneeded dependencies using the patchelf tool. These get packaged into an RPM and installed on my runtime system. After the install, ldconfig gets called, and strange links are created. The locations of the patched libraries on the runtime system is something like /usr1/blah/lib and a few subfolders. This location and the location of the subfolders is specified in my /etc/ld.so.conf file. When I run ldconfig, a bunch of links with strange names are created, such as: ?N -> libFoo.so ??r? -> libBar.so as well as links whose names are partial function names of functions in the library, e.g. if I do objdump -x and look at the function names, the link will have part of that function as its name. My understanding was that ldconfig looks at the SONAME of the libraries and creates a link with that name. However when I do an objdump -x on all the affected libraries and grep for SONAME, nothing is out of the ordinary, they all end in .so and have none of the weird question marks. ldconfig -v provides no helpful information. Any ideas as to what could be going on? Maybe the SONAME is getting screwed up in some way that I'm missing? Thanks for any help. edit: if I merely remove dependencies as a part of my patching process (e.g. only call patchelf --remove-needed , then this issue doesn't happen. it's only when I use the --add-needed flag. edit 2: If I just add and remove a garbage dependency (e.g. patchelf --add-needed garbage libFoo.so followed immediately by patchelf --remove-needed garbage libFoo.so), that causes the weird link issue as well. The final dependency list in each library is the exact same, and it works when I just use the --remove-needed flag, which leads me to think that the issue is the --add-needed flag and whatever patchelf does to the header when it does that. edit 3: at this point I am going with the assumption that this is a bug with either patchelf or ldconfig. I'm guessing it's the latter since we're using glibc version 2.17 which is from ~2012, but the latest version of patchelf. perhaps the ELF standard has changed. tl;dr with patchelf version 0.10 and glibc version 2.17, the --add-needed option appears to mess with the ELF such that ldconfig is creating some wonky links.

The context is as follows: on my o.s. there is (already) *liba.so.v2* of "liba" which contains the string 'symbol_version-2' as the symbol version for its functions , e.g. *functionX@version-2* (in my case, for ex. *wrefresh@NCURSES6_5.0.19991023* in *objdump -T / readelf* output). There is this new *binary_a* which I downloaded and want to run. This, however, has a dependency for a previous versions of the lib, *liba.so.v1*, which contains a different symbol version string, e.g. 'symbol_version-1' (in my case *wrefresh@NCURSES_5.0.19991023* (notice the missing '6'). Notes: - The functions (all of them) exist in both so libs and the new lib is **found** by ld.so (checked that using

=libs ldd ./binary_a

) - The binary unfortunately doesn't have any reference to the 'new' symbol, otherwise, it would be easy to hexedit the binary , and adjust the *vna_flags* (see NewAppsOnOldGlibc link below) My questions are : 1. **how to patch the binary such as to refer to the new symbol in the new lib** - using either dedicated Tools (objcopy / elfedit, others ...?), or even hexedit. For the latter case I'd need please step-by-step advice on how to recalculate the hashes (if needed; according to link it seems it's needed). There seems to be enough details in dynTable-hash , however the information presented there is too complicated for me to make any practical use of for my use-case. 2. Why is *ld.so* (still) complaining that "it cannot find version", after I've hexedit out all references to the old lib.so and the old symbol ? *Is ld.so's cache somehow interferring ?* All my attempts led to ldd (actually ld.so) complaining after patching the file, that it cannot find the new symbol version... The ideal solution would avoid (re)compiling stuff (i.e. the *binary_a*) , except maybe compiling a 'dummy' function like in previous link, would avoid using LD_PRELOADs variables. **What I've tried:** - In my tests with *patchelf*, it produced a corrupt binary with flags *--remove-needed liba.so.v2* ; using *patchelf --replace-needed liba.so.v2 liba.so.v1* did rearrange the 'physical' layout of the file (as viewed with hexedit), but the symbols still referenced the v2 so lib, so I have doubts that this option worked as intended .To add more info: am hitting this with patchelf. The 'rearrangement' of the binary, seems it is referred to be *patchelf --debug* when among other lines it says:

shifting new PT_LOAD segment by %d bytes to work around a Linux kernel bug

- Testing with *elfsh* yielded another error, upon loading the binary, don't have it in front of me know, but somthing like: *'elf header AMD64-x64 not recognized'* - When 'hexediting' **another ** binary, where the symbol versions had the **same** string length (not like in this case, where there is a one char difference in the version string length) - so, an easier case - doing *ldd* on the resulted binary still complained that "symbol_version-2" not found. I would imagine adding a new entry ("symbol_version-2" ) in the *.dynstr* Table is not feasible (i.e. without decompiling the binary), is it ? If that would be doable, then I'd simply hexedit (overwrite) in the *vna_flags* field of *Elfxx_Vernaux* entry corresponding to the 'old' symbol, to be the offset (in the .dynstr Table) of this new string, i.e. "symbol_version-2", again along the lines of NewAppsOnOldGlibc Would following help - (a) changing the *soname* inside the lib.so.v2 file (using

--set-soname

or similar), (b) renaming the *lib.so.v2* file to *lib.so.v1* and (c) fiddling with the version name (string) **only** ? This would lead me again to asking: how would i trick *ld.so* into accepting my manual modification to the binary ? Thanks in advance for your help !

I have a legacy system with a very old glibc, which we can't upgrade without incurring a mountain of testing/validation work. I have needed to run newer programs (such as Java 1.7) on that system several times now. I opted for a chroot solution, where I package up all the needed libs, and run a service in a chroot. The chroot is very limiting though, and I'd rather try to solve the problem with LD_LIBRARY_PATH. Unfortunately, I get an error about libc.so.6: cannot handle TLS data when I try that. It turns out I need the /lib/ld-linux.so.2 from the chroot as well. This works: LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program However, java foils my trick by inspecting /proc/self/cmdline to determine where to load its libraries from, which fails if the binary wasn't named 'bin/java'. Also java execs itself during startup, further complicating matters. In a last-ditch attempt to make this work, I opened the java binary with a hex editor and replaced the string /lib/ld-linux.so.2 with /home/chroot/ld.so (and made that a symlink to ld-linux.so.2), and it worked! But I think everyone would agree that it is a massive kludge to rewrite the path of every new binary to an absolute path of the nested system. Does anyone know a cleaner way to use a custom library path **including** a custom ld-linux.so?

#Resume I am currently trying to install dot-net-core-sdk 2.0 with the Nix package manager in NixOs. I am very new to both NixOs, Nix, bash scripting and stuff like ELF. Yet I think I've successfully managed to create a valid Nix package description for dot-net-core-sdk 2.0. However, when I try to create a new console project it complains that it can't find the console template: No templates matched the input template name: console. #The long story... I have defined my Nix package and build script as follows: **dotnet-sdk.nix** with import {}; stdenv.mkDerivation { name = "dotnet-sdk-2.0"; builder = ./builder.sh; libPath = stdenv.lib.makeLibraryPath [ lttng-tools kerberos zlib gettext openssl icu libunwind eject stdenv.cc.cc glib ]; src = fetchurl { url = "https://download.microsoft.com/download/1/B/4/1B4DE605-8378-47A5-B01B-2C79D6C55519/dotnet-sdk-2.0.0-linux-x64.tar.gz "; sha256 = "6059a6f72fb7aa6205ef4b52583e9c041fd128e768870a0fc4a33ed84c98ca6b"; }; } **builder.sh** source $stdenv/setup mkdir -p $out/dotnet-sdk echo "unpacking $src..." tar xvfa $src -C $out/dotnet-sdk echo "unpacking dotnet-sdk..." p=$out/libexec/dotnet mkdir -p $out/libexec mv $out/dotnet-sdk $p ls -lrth $p patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" --force-rpath --set-rpath $libPath --debug $p/dotnet echo "libPath" echo $libPath mkdir -p $out/bin ln -s $p/dotnet $out/bin/dotnet I can successfully build the package with $ sudo nix-build dotnet-sdk.nix Which results in a long output that ends with ... unpacking dotnet-sdk... total 136K -rw-r--r-- 1 nixbld1 nixbld 8.0K Jul 20 23:06 ThirdPartyNotices.txt -rw-r--r-- 1 nixbld1 nixbld 1.1K Jul 20 23:06 LICENSE.txt -rwxr-xr-x 1 nixbld1 nixbld 104K Jul 20 23:16 dotnet drwxr-xr-x 3 nixbld1 nixbld 4.0K Aug 3 19:34 store drwxr-xr-x 3 nixbld1 nixbld 4.0K Aug 3 19:34 shared drwxr-xr-x 3 nixbld1 nixbld 4.0K Aug 3 19:34 sdk drwxr-xr-x 3 nixbld1 nixbld 4.0K Aug 3 19:34 host drwxr-xr-x 4 nixbld1 nixbld 4.0K Aug 3 19:34 additionalDeps patching ELF file `/nix/store/f1sankahbj7pss7vjrvbmng9z7gd08a6-dotnet-sdk-2.0/libexec/dotnet/dotnet' Kernel page size is 4096 bytes new rpath is `/nix/store/xdv40bsxp4c7m2nw63nrnkadmivczk24-lttng-tools-2.9.3/lib:/nix/store/b7yiqkykhj3lr7dlb3v81rsdasjg32jw-libkrb5-1.15/lib:/nix/store/sg6ri2jj92sbv7f4rvchzr00d24pi4nq-zlib-1.2.11/lib:/nix/store/s70cbg1lh45h3gl6xplz6bi2qdszi2cf-gettext-0.19.8/lib:/nix/store/b6d4mxvj5wdnf28lpww73pllmm0zd2nv-openssl-1.0.2l/lib:/nix/store/03gqmzrbh1pr5izy24gmyw1bfdzpy6q8-icu4c-58.2/lib:/nix/store/f4xflmvgszhrwa1r1jn5fddz8j196qzv-libunwind-1.1/lib:/nix/store/awxn3kfww8hjnd1pyji4zdmmi2x3kvzb-util-linux-2.29.2/lib:/nix/store/lc9cdddv2xv45ighz8znsanjfgkcdgbx-gcc-5.4.0-lib/lib:/nix/store/75pmwxf02m6i4vd3b0iybc3w54xf4r2z-glib-2.50.3/lib' rpath is too long, resizing... DT_NULL index is 28 replacing section `.dynamic' with size 560 replacing section `.dynstr' with size 22942 replacing section `.interp' with size 80 this is an executable using replaced section `.interp' using replaced section `.dynstr' using replaced section `.dynamic' last replaced is 22 looking at section `.interp' looking at section `.note.ABI-tag' replacing section `.note.ABI-tag' which is in the way looking at section `.note.gnu.build-id' replacing section `.note.gnu.build-id' which is in the way looking at section `.hash' replacing section `.hash' which is in the way looking at section `.dynsym' replacing section `.dynsym' which is in the way looking at section `.dynstr' looking at section `.gnu.version' first reserved offset/addr is 0x8a38/0x408a38 first page is 0x400000 needed space is 36624 needed space is 36680 needed pages is 1 changing alignment of program header 2 from 2097152 to 4096 changing alignment of program header 3 from 2097152 to 4096 clearing first 38856 bytes rewriting section `.dynamic' from offset 0x19da8 (size 544) to offset 0x270 (size 560) rewriting section `.dynstr' from offset 0x4308 (size 22320) to offset 0x4a0 (size 22942) rewriting section `.dynsym' from offset 0x1d10 (size 9720) to offset 0x5e40 (size 9720) rewriting section `.hash' from offset 0x1298 (size 2680) to offset 0x8438 (size 2680) rewriting section `.interp' from offset 0x1238 (size 28) to offset 0x8eb0 (size 80) rewriting section `.note.ABI-tag' from offset 0x1254 (size 32) to offset 0x8f00 (size 32) rewriting section `.note.gnu.build-id' from offset 0x1274 (size 36) to offset 0x8f20 (size 36) rewriting symbol table section 3 libPath /nix/store/xdv40bsxp4c7m2nw63nrnkadmivczk24-lttng-tools-2.9.3/lib:/nix/store/b7yiqkykhj3lr7dlb3v81rsdasjg32jw-libkrb5-1.15/lib:/nix/store/sg6ri2jj92sbv7f4rvchzr00d24pi4nq-zlib-1.2.11/lib:/nix/store/s70cbg1lh45h3gl6xplz6bi2qdszi2cf-gettext-0.19.8/lib:/nix/store/b6d4mxvj5wdnf28lpww73pllmm0zd2nv-openssl-1.0.2l/lib:/nix/store/03gqmzrbh1pr5izy24gmyw1bfdzpy6q8-icu4c-58.2/lib:/nix/store/f4xflmvgszhrwa1r1jn5fddz8j196qzv-libunwind-1.1/lib:/nix/store/awxn3kfww8hjnd1pyji4zdmmi2x3kvzb-util-linux-2.29.2/lib:/nix/store/lc9cdddv2xv45ighz8znsanjfgkcdgbx-gcc-5.4.0-lib/lib:/nix/store/75pmwxf02m6i4vd3b0iybc3w54xf4r2z-glib-2.50.3/lib /nix/store/f1sankahbj7pss7vjrvbmng9z7gd08a6-dotnet-sdk-2.0 I can now successfully execute the help and version functions on the dotnet binary without getting weird errors about missing object files: $ result/bin/dotnet --version 2.0.0 **However**, when I try to create a new console application I get following error: $ /etc/nixos/dotnet-sdk/result/bin/dotnet new console No templates matched the input template name: console. Templates Short Name Language Tags ------------------------------------------------- I have no idea why it can't find the templates, but I have a weak hypothesis that maybe I screwed something up in the binary by using --force-rpath when I modify the binary with patchelf in the buildscript.. - **Does my package configuration and buildscript look okay?** *(eg. is the problem unrelated to my Nix package description and buildscript)* - **Is there something obvious I am missing, such as somehow providing a link to some of the auxiliary net core directories when modifying the binary with patchelf?** - **Something else I can do to make net core sdk 2.0 work in NixOs?**

I am testing how dynamic linking works with RUNPATH variable, and trying to run bash in a minimal chroot directory: $ find dir_chroot/ -type f dir_chroot/bin/bash dir_chroot/lib/x86_64-linux-gnu/libc.so.6 dir_chroot/lib/x86_64-linux-gnu/libdl.so.2 dir_chroot/lib/x86_64-linux-gnu/libtinfo.so.5 dir_chroot/lib64/ld-linux-x86-64.so.2 -- these are all dependencies of bash, and they are actual binaries (find -type f), not symbolic links. Also they don't have RUNPATH: $ find dir_chroot/ -type f -exec sh -c "readelf -d {} | grep RUNPATH" \; $ chroot works fine with this directory: $ sudo chroot dir_chroot /bin/bash bash-4.3# exit exit However, if I copy everything and set RUNPATH to $ORIGIN/ in lib64/ld-linux-x86-64.so.2 I get exit code 139 (segfault?) when running chroot: $ cp -R dir_chroot dir_chroot4 $ find dir_chroot4/ -type f -exec sh -c "echo {} readelf -d {} | grep RUNPATH" \; dir_chroot4/bin/bash dir_chroot4/lib/x86_64-linux-gnu/libc.so.6 dir_chroot4/lib/x86_64-linux-gnu/libdl.so.2 dir_chroot4/lib/x86_64-linux-gnu/libtinfo.so.5 dir_chroot4/lib64/ld-linux-x86-64.so.2 $ $ patchelf --set-rpath "\$ORIGIN/" dir_chroot4/lib64/ld-linux-x86-64.so.2 $ find dir_chroot4/ -type f -exec sh -c "echo {} readelf -d {} | grep RUNPATH" \; dir_chroot4/bin/bash dir_chroot4/lib/x86_64-linux-gnu/libc.so.6 dir_chroot4/lib/x86_64-linux-gnu/libdl.so.2 dir_chroot4/lib/x86_64-linux-gnu/libtinfo.so.5 dir_chroot4/lib64/ld-linux-x86-64.so.2 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/] $ $ sudo chroot dir_chroot4 /bin/bash $ $ echo $status 139 -- $status is the status variable in fish shell. It happens only if ld-linux-x86-64.so.2 is patched, other libraries and bash executable work ok with RUNPATH. Why is it so?

I tried to install the current oracle jre on a VM running NixOS. Now the following happens: [michas@cc:~]$ tar xvzf jre-7u40-linux-x64.tar.gz |grep bin/java jre1.7.0_40/bin/javaws jre1.7.0_40/bin/java_vm jre1.7.0_40/bin/java [michas@cc:~]$ ls -l ./jre1.7.0_40/bin/java -rwxr-xr-x 1 michas nogroup 7750 Aug 27 09:17 ./jre1.7.0_40/bin/java [michas@cc:~]$ ./jre1.7.0_40/bin/java bash: ./jre1.7.0_40/bin/java: No such file or directory WTF? The named file is obviously there. What is going on? Trying to analyse further: [michas@cc:~]$ strace ./jre1.7.0_40/bin/java execve("./jre1.7.0_40/bin/java", ["./jre1.7.0_40/bin/java"], [/* 53 vars */]) = -1 ENOENT (No such file or directory) write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory ) = 40 exit_group(1) = ? +++ exited with 1 +++ [michas@cc:~]$ strace ./jre1.7.0_40/bin/jav strace: Can't stat './jre1.7.0_40/bin/jav': No such file or directory Ok, the output of a really missing file looks different. [michas@cc:~]$ file ./jre1.7.0_40/bin/java ./jre1.7.0_40/bin/java: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, BuildID[sha1]=a558f547fe0b95fdc6a109cb7d9692d6d7969794, not stripped [michas@cc:~]$ file ~/t /home/michas/t: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped The latter is a tiny self compiled binary running without problems. Both look very similar. Hence format the binary itself seems to be fine. [michas@cc:~]$ ldd ./jre1.7.0_40/bin/java /run/current-system/sw/bin/ldd: line 116: ./jre1.7.0_40/bin/java: No such file or directory Seems like there is a problem regarding the needed shared libraries. What is going on and how can I fix it?

I know there are similar questions out there, but I haven't found a solution nor this exact case. The binary was built on Arch Linux using its GCC 4.7. The package works fine on the build system. The commands below were executed on: > Linux vbox-ubuntu 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux The file in question is located here . It's a Linux 64-bit to Windows 64-bit cross-compiler. Untarring it to ~/ gives a single ~/mingw64 directory which contains everything needed. When I try to run ~/mingw64/x86_64-w64-mingw32/bin/as this is what I get: bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory Running file ~/mingw64/x86_64-w64-mingw32/bin/as gives me: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped Running ldd ~/mingw64/x86_64-w64-mingw32/bin/as gives me: linux-vdso.so.1 => (0x00007fff3e367000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000) I am truly at a loss. Any help is much appreciated. **EDIT**: Some more details: The build system is Arch Linux (currently glibc 2.16). The output of ls -l is: -rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as The output of objdump -p is: Version References: required from libz.so.1: 0x0827e5c0 0x00 05 ZLIB_1.2.0 required from libc.so.6: 0x0d696917 0x00 06 GLIBC_2.7 0x06969194 0x00 04 GLIBC_2.14 0x0d696913 0x00 03 GLIBC_2.3 0x09691a75 0x00 02 GLIBC_2.2.5 The output of ldd -v on Ubuntu 12.04 is: linux-vdso.so.1 => (0x00007fff225ff000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000) Version information: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libz.so.1: libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 The tested other OSes are Fedora 17 (glibc 2.15) and Ubuntu 12.04 (eglibc 2.15). Both zlib and glibc version requirements are met.

I am looking for alternative of install_name_tool of MAC in CentOS. Exactly I want to build MySQL on non default location. Also the shared libraries of the mysql binary should be on non default location and properly linked. I wasnt able to link shared libraries libssl & libcrypto to the mysqld binary. [user@localhost mysql]$ ldd /usr/local/mysql/bin/mysqld linux-gate.so.1 => (0x00186000) libpthread.so.0 => /lib/libpthread.so.0 (0x008e2000) libz.so.1 => /lib/libz.so.1 (0x0097f000) librt.so.1 => /lib/librt.so.1 (0x00912000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00c70000) libdl.so.2 => /lib/libdl.so.2 (0x00727000) libssl.so.1.0.0 => not found libcrypto.so.1.0.0 => not found libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a7e000) libm.so.6 => /lib/libm.so.6 (0x008b0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a70000) libc.so.6 => /lib/libc.so.6 (0x00755000) /lib/ld-linux.so.2 (0x00731000) I am sure that openssl is installed in /usr/local/extra directory as i also installed apache perfectly, which is currently working, my configure command is : cmake . -LH -DCMAKE_INCLUDE_PATH=/usr/local/extra/include -DCMAKE_LIBRARY_PATH=/usr/local/extra/lib -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr/local/mysql -DMYSQL_DATADIR=/usr/local/var -DSYSCONFDIR=/usr/local/mysql/etc -DMYSQL_UNIX_ADDR=/usr/local/mysql/tmp/mysql.sock -DCURSES_LIBRARY=/usr/local/extra/lib/libncurses.so.5 -DCURSES_INCLUDE_PATH=/usr/local/extra/include -DWITH_SSL=yes -DWITH_ZLIB=system While configuring it also shows : -- checking for module 'openssl' -- found openssl, version 0.9.8e-rhel5 -- Found OpenSSL: /usr/local/extra/lib/libssl.so;/usr/local/extra/lib/libcrypto.so (found version "1..") Can any one suggest me a tool to link shared libraries to the binary.