Versão curta

Rápido e sujo: verifique se steam-runestá instalado (nome estranho, não tem nada a ver com steam), por exemplo nix-shell -p steam-run, então:

$ steam-run ./your-binary

Aqui está uma explicação mais longa e detalhada, juntamente com vários métodos, muitas vezes menos sujos. Desde a criação desta resposta, outras alternativas ao steam-run foram desenvolvidas, veja por exemplo nix-ld (que basicamente recria os carregadores ausentes em /lib) e nix-alien / nix-autobahn que também tenta adicionar automaticamente as bibliotecas ausentes. Finalmente, você pode usar o distrobox que fornece qualquer distribuição em um contêiner docker/podman totalmente integrado ao host.

Versão longa

Aqui estão vários métodos (os manuais são principalmente para fins educacionais, pois na maioria das vezes é melhor escrever uma derivação adequada). Não sou especialista em nada, e fiz essa lista também para aprender nix, então se você tiver métodos melhores, me avise!

Portanto, o principal problema é que o executável chama primeiro um carregador e, em seguida, precisa de algumas bibliotecas para funcionar, e o nixos coloca o carregador e as bibliotecas em arquivos /nix/store/.

Esta lista fornece todos os métodos que encontrei até agora. Existem basicamente três "grupos":

• o manual completo: interessante para fins educacionais, e para entender o que está acontecendo, mas é só (não os use na prática porque nada impedirá que as derivações costumavam ser coletadas de lixo depois)
• as versões corrigidas: esses métodos tentam modificar o executável (automaticamente ao usar o método recomendado 4 com autoPatchelfHook) para apontar diretamente para a boa biblioteca
• os métodos baseados em FHS, que basicamente falsificam um "linux normal" (mais pesado para rodar do que a versão corrigida, então isso deve ser evitado se possível).

Eu recomendaria o método 4 autoPatchelfHookpara uma configuração real e adequada, e se você não tiver tempo e quiser apenas executar um binário em uma linha, poderá estar interessado na solução rápida e suja baseada em steam-run(método 7 ).

Método 1) Método manual sujo, sem patch

Você precisa primeiro encontrar o carregador com, por exemplo file:

$ file wolframscript
wolframscript: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=079684175aa38e3633b60544681b338c0e8831e0, stripped

Aqui está o carregador /lib64/ld-linux-x86-64.so.2. Para encontrar o carregador de nixos, você pode fazer:

$ ls /nix/store/*glibc*/lib/ld-linux-x86-64.so.2
/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2

Você também precisa encontrar para encontrar as bibliotecas que seu programa requer, por exemplo com lddou LD_DEBUG=libs:

$ ldd wolframscript
        linux-vdso.so.1 (0x00007ffe8fff9000)
        libpthread.so.0 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/libpthread.so.0 (0x00007f86aa321000)
        librt.so.1 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/librt.so.1 (0x00007f86aa317000)
        libdl.so.2 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/libdl.so.2 (0x00007f86aa312000)
        libstdc++.so.6 => not found
        libm.so.6 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/libm.so.6 (0x00007f86aa17c000)
        libgcc_s.so.1 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/libgcc_s.so.1 (0x00007f86a9f66000)
        libc.so.6 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/libc.so.6 (0x00007f86a9dae000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007f86aa344000)

Aqui, você vê que a maioria das bibliotecas são encontradas, exceto libstdc++.so.6. Então vamos encontrá-los! Uma primeira maneira rápida e suja de encontrá-los é verificar se eles já estão presentes em seu sistema:

$ find /nix/store -name libstdc++.so.6
/nix/store/12zhmzzhrwszdc8q3fwgifpwjkwi3mzc-gcc-7.3.0-lib/lib/libstdc++.so.6

Caso a biblioteca ainda não esteja instalada, você certamente preferirá usar o nix-indexprograma mais envolvido para buscar esses arquivos em um banco de dados muito maior (obrigado hydra). Para isso, primeiro instale nix-indexe gere o banco de dados (isso só é necessário na primeira vez, mas pode levar alguns minutos para ser executado):

$ nix-index

(você também pode usar nix nix-index-update- alien para baixar o cache automaticamente do nix-index-database ) então, para procurar uma biblioteca, você pode fazer algo como (observe que --top-levelremove algumas entradas):

$ nix-locate lib/libstdc++.so.6 --top-level
…
gcc-unwrapped.lib                                     0 s /nix/store/7fv9v6mnlkb4ddf9kz1snknbvbfbcbx0-gcc-10.3.0-lib/lib/libstdc++.so.6
…

Então você pode instalar essas bibliotecas para este exemplo rápido e sujo (mais tarde veremos soluções melhores).

Bom. Agora, só precisamos executar o programa com o LD_LIBRARY_PATHconfigurado para apontar para este arquivo (veja também makeLibraryPathpara gerar esta string em uma derivação), e chamar o loader que determinamos no primeiro passo neste arquivo:

LD_LIBRARY_PATH=/nix/store/12zhmzzhrwszdc8q3fwgifpwjkwi3mzc-gcc-7.3.0-lib/lib/:$LD_LIBRARY_PATH /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2 ./wolframscript

(certifique-se de usar ./antes do nome do script, e de manter apenas o diretório das bibliotecas. Se você tiver várias bibliotecas, basta usar concat o caminho com dois pontos)

Método 2) Método manual sujo, com patch

Depois de instalar (com nixenv -iou no seu configuration.nix) patchelf, você também pode modificar diretamente o executável para empacotar o bom carregador e as bibliotecas. Para alterar o carregador basta executar:

patchelf --set-interpreter /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2 wolframscript

e para verificar:

$ patchelf --print-interpreter wolframscript
/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.

e para alterar o caminho para as bibliotecas codificadas no executável, primeiro verifique qual é o rpath atual (vazio para mim):

$ patchelf --print-rpath wolframscript

e anexá-los ao caminho da biblioteca que você determinou antes, eventualmente separados por dois pontos:

$ patchelf --set-rpath /nix/store/12zhmzzhrwszdc8q3fwgifpwjkwi3mzc-gcc-7.3.0-lib/lib/ wolframscript
$ ./wolframscript

Método 3) Patch em uma derivação nix

Podemos reproduzir mais ou menos a mesma coisa em uma derivação nix inspirada no skypeforlinux

Este exemplo apresenta também uma alternativa, você pode usar:

patchelf --set-interpreter ${glibc}/lib/ld-linux-x86-64.so.2 "$out/bin/wolframscript" || true

(que deve ficar bem claro quando você entender o método "manual"), ou

patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" "$out/bin/wolframscript" || true

Este segundo método é um pouco mais sutil, mas se você executar:

$ nix-shell '<nixpkgs>' -A hello --run 'echo $NIX_CC/nix-support/dynamic-linker "->" $(cat $NIX_CC/nix-support/dynamic-linker)'
/nix/store/8zfm4i1aw4c3l5n6ay311ds6l8vd9983-gcc-wrapper-7.4.0/nix-support/dynamic-linker -> /nix/store/sw54ph775lw7b9g4hlfvpx6fmlvdy8qi-glibc-2.27/lib/ld-linux-x86-64.so.2

você verá que o arquivo $NIX_CC/nix-support/dynamic-linkercontém um caminho para o carregador ld-linux-x86-64.so.2.

Coloque derivation.nix, isso é

{ stdenv, dpkg,glibc, gcc-unwrapped }:
let

  # Please keep the version x.y.0.z and do not update to x.y.76.z because the
  # source of the latter disappears much faster.
  version = "12.0.0";

  rpath = stdenv.lib.makeLibraryPath [
    gcc-unwrapped
    glibc
  ];
  # What is it for?
  # + ":${stdenv.cc.cc.lib}/lib64";

  src = ./WolframScript_12.0.0_LINUX64_amd64.deb;

in stdenv.mkDerivation {
  name = "wolframscript-${version}";

  system = "x86_64-linux";

  inherit src;

  nativeBuildInputs = [
  ];

  buildInputs = [ dpkg ];

  unpackPhase = "true";

  # Extract and copy executable in $out/bin
  installPhase = ''
    mkdir -p $out
    dpkg -x $src $out
    cp -av $out/opt/Wolfram/WolframScript/* $out
    rm -rf $out/opt
  '';

  postFixup = ''
    # Why does the following works?
    patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" "$out/bin/wolframscript" || true
    # or
    # patchelf --set-interpreter ${glibc}/lib/ld-linux-x86-64.so.2 "$out/bin/wolframscript" || true
    patchelf --set-rpath ${rpath} "$out/bin/wolframscript" || true
  '';

  meta = with stdenv.lib; {
    description = "Wolframscript";
    homepage = https://www.wolfram.com/wolframscript/;
    license = licenses.unfree;
    maintainers = with stdenv.lib.maintainers; [ ];
    platforms = [ "x86_64-linux" ];
  };
}

e default.nixcolocando:

{ pkgs ? import <nixpkgs> {} }:

pkgs.callPackage ./derivation.nix {}

Compile e execute com

nix-build
result/bin/wolframscript

Método 4) Use autoPatchElf: mais simples

Todos os métodos anteriores precisam de um pouco de trabalho (você precisa encontrar os executáveis, corrigi-los...). NixOs fez para nós um "gancho" especial autoPatchelfHookque automaticamente corrige tudo para você! Você só precisa especificá-lo em (native)BuildInputs, e nix faz a mágica.

{ stdenv, dpkg, glibc, gcc-unwrapped, autoPatchelfHook }:
let

  # Please keep the version x.y.0.z and do not update to x.y.76.z because the
  # source of the latter disappears much faster.
  version = "12.0.0";

  src = ./WolframScript_12.0.0_LINUX64_amd64.deb;

in stdenv.mkDerivation {
  name = "wolframscript-${version}";

  system = "x86_64-linux";

  inherit src;

  # Required for compilation
  nativeBuildInputs = [
    autoPatchelfHook # Automatically setup the loader, and do the magic
    dpkg
  ];

  # Required at running time
  buildInputs = [
    glibc
    gcc-unwrapped
  ];

  unpackPhase = "true";

  # Extract and copy executable in $out/bin
  installPhase = ''
    mkdir -p $out
    dpkg -x $src $out
    cp -av $out/opt/Wolfram/WolframScript/* $out
    rm -rf $out/opt
  '';

  meta = with stdenv.lib; {
    description = "Wolframscript";
    homepage = https://www.wolfram.com/wolframscript/;
    license = licenses.mit;
    maintainers = with stdenv.lib.maintainers; [ ];
    platforms = [ "x86_64-linux" ];
  };
}

Método 5) Use o FHS para simular um shell linux clássico e execute manualmente os arquivos

Alguns softwares podem ser difíceis de empacotar dessa maneira porque podem depender muito da estrutura da árvore de arquivos FHS ou podem verificar se o binário não foi alterado. Você também pode usar buildFHSUserEnv para fornecer uma estrutura de arquivo FHS (leve, usando namespaces) para seu aplicativo. Observe que esse método é mais pesado que os métodos baseados em patch e adiciona um tempo de inicialização significativo, portanto, evite-o quando possível

Você pode apenas gerar um shell e extrair manualmente o arquivo e executar o arquivo, ou empacotar diretamente seu programa para o FHS. Vamos primeiro ver como obter um shell. Coloque em um arquivo (digamos fhs-env.nix) o seguinte:

let nixpkgs = import <nixpkgs> {};
in nixpkgs.buildFHSUserEnv {
   name = "fhs";
   targetPkgs = pkgs: [];
   multiPkgs = pkgs: [ pkgs.dpkg ];
   runScript = "bash";
}

e corra:

nix-build fhs-env.nix
result/bin/fhs

Você obterá um bash em um linux com aparência mais padrão e poderá executar comandos para executar seu executável, como:

mkdir wolf_fhs/
dpkg -x WolframScript_12.0.0_LINUX64_amd64.deb wolf_fhs/
cd wolf_fhs/opt/Wolfram/WolframScript/bin/
./wolfram

Se você precisar de mais bibliotecas/programas como dependências, basta adicioná-los a multiPkgs(para todos os arcos suportados) ou targetPkgs(somente para o arco atual).

Bônus: você também pode iniciar um shell fhs com um comando de uma linha, sem criar um arquivo específico:

nix-build -E '(import <nixpkgs> {}).buildFHSUserEnv {name = "fhs";}' && ./result/bin/fhs

Método 6) Use o FHS para simular um shell linux clássico e empacote os arquivos dentro

fonte: https://reflexivereflection.com/posts/2015-02-28-deb-installation-nixos.html

Método 7) a vapor

Com buildFHSUserEnvvocê pode executar muitos softwares, mas você precisará especificar manualmente todas as bibliotecas necessárias. Se você deseja uma solução rápida e não tem tempo para verificar exatamente quais são as bibliotecas necessárias, tente steam-run(apesar do nome, não está vinculado diretamente ao steam e apenas contém muitas bibliotecas), o que é como buildFHSUserEnvcom muitas bibliotecas comuns pré-instaladas (algumas delas podem ser não-livres como steamrtaquela que contém algum código nvidia, obrigado simpson!). Para usá-lo, basta instalar steam-rune depois:

steam-run ./wolframscript

ou se você quiser um shell completo:

steam-run bash

Observe que você pode precisar adicionar nixpkgs.config.allowUnfree = true;(ou colocar na lista de permissões este pacote específico ) se quiser instalá-lo com nixos-rebuild, e se quiser executá-lo/instalá-lo com nix-shell/ nix-envvocê precisa colocar .{ allowUnfree = true; }~/.config/nixpkgs/config.nix

Não é fácil "sobrescrever" pacotes ou bibliotecas no nix-shell, mas se você quiser criar um wrapper em torno de seu script, poderá criar manualmente um script wrapper:

#!/usr/bin/env nix-shell
#!nix-shell -i bash -p steam-run
exec steam-run ./wolframscript "$@"

ou escreva-o diretamente em uma derivação nixos:

{ stdenv, steam-run, writeScriptBin }:
let
  src = ./opt/Wolfram/WolframScript/bin/wolframscript;
in writeScriptBin "wolf_wrapped_steam" ''
    exec ${steam-run}/bin/steam-run ${src} "$@"
  ''

ou se você começar a partir do .deb (aqui eu usei makeWrapper):

{ stdenv, steam-run, dpkg, writeScriptBin, makeWrapper }:
stdenv.mkDerivation {
  name = "wolframscript";
  src = ./WolframScript_12.0.0_LINUX64_amd64.deb;

  nativeBuildInputs = [
    dpkg makeWrapper
  ];
  unpackPhase = "true";
  installPhase = ''
    mkdir -p $out/bin
    dpkg -x $src $out
    cp -av $out/opt/Wolfram/WolframScript/bin/wolframscript $out/bin/.wolframscript-unwrapped
    makeWrapper ${steam-run}/bin/steam-run $out/bin/wolframscript --add-flags $out/bin/.wolframscript-unwrapped
    rm -rf $out/opt
  '';
}

(se você está muito cansado para escrever o usual default.nix, você pode executar diretamente nix-build -E "with import <nixpkgs> {}; callPackage ./derivation.nix {}")

Método 8) Usandonix-ld

Se você não quiser gerar um sandbox como fizemos para o steam-run (em sandboxes é impossível executar aplicativos setuid, sandboxes não podem ser aninhados, integração ruim com os pacotes do sistema incluídos direnv), você pode recriar o sistema de carregador ausente -wide colocando em seu configuration.nix:

  programs.nix-ld.enable = true;

Você pode ver que o arquivo agora está presente:

$ ls /lib64/
ld-linux-x86-64.so.2

No entanto, ainda é impossível executar binários, pois o novo ld-linux-x86-64.so.2arquivo redireciona apenas para o carregador NIX_LD(desta forma, vários programas podem usar carregadores diferentes enquanto estão no mesmo sistema):

$ ./blender 
cannot execute ./blender: NIX_LD or NIX_LD_x86_64-linux is not set

Para criar localmente essa variável de ambiente, você pode fazer algo como:

$ cat shell.nix 
with import <nixpkgs> {};
mkShell {
  NIX_LD_LIBRARY_PATH = lib.makeLibraryPath [
    stdenv.cc.cc
    openssl
    # ...
  ];
  NIX_LD = lib.fileContents "${stdenv.cc}/nix-support/dynamic-linker";
}

$ nix-shell 

[nix-shell:/tmp/blender-3.2.2-linux-x64]$ ./blender

ou em todo o sistema usando:

  environment.variables = {
      NIX_LD_LIBRARY_PATH = lib.makeLibraryPath [
        pkgs.stdenv.cc.cc
        pkgs.openssl
        # ...
      ];
      NIX_LD = lib.fileContents "${pkgs.stdenv.cc}/nix-support/dynamic-linker";
  };

Observe que você precisa reiniciar sua sessão do X11 toda vez que alterar este arquivo ou fizer:

$ cat /etc/profile | grep set-environment
. /nix/store/clwf7wsykkjdhbd0v8vb94pvg81lnsba-set-environment
$ . /nix/store/clwf7wsykkjdhbd0v8vb94pvg81lnsba-set-environment

Note that (contrary to steam-run) nix-ld does not come with any library by default but you can add your own or use tools to do that automatically, see below. You can also get inspired by the list of libraries that steam-run packs here: https://github.com/NixOS/nixpkgs/blob/master/pkgs/games/steam/fhsenv.nix Here is for example the file I'm using for now, it is enough to run blender:

  # Automatically creates a loader in /lib/* to avoid patching stuff
  programs.nix-ld.enable = true;
  environment.variables = {
      NIX_LD_LIBRARY_PATH = with pkgs; lib.makeLibraryPath [
        stdenv.cc.cc
        openssl
        xorg.libXcomposite
        xorg.libXtst
        xorg.libXrandr
        xorg.libXext
        xorg.libX11
        xorg.libXfixes
        libGL
        libva
        pipewire.lib
        xorg.libxcb
        xorg.libXdamage
        xorg.libxshmfence
        xorg.libXxf86vm
        libelf
        
        # Required
        glib
        gtk2
        bzip2
        
        # Without these it silently fails
        xorg.libXinerama
        xorg.libXcursor
        xorg.libXrender
        xorg.libXScrnSaver
        xorg.libXi
        xorg.libSM
        xorg.libICE
        gnome2.GConf
        nspr
        nss
        cups
        libcap
        SDL2
        libusb1
        dbus-glib
        ffmpeg
        # Only libraries are needed from those two
        libudev0-shim
        
        # Verified games requirements
        xorg.libXt
        xorg.libXmu
        libogg
        libvorbis
        SDL
        SDL2_image
        glew110
        libidn
        tbb
        
        # Other things from runtime
        flac
        freeglut
        libjpeg
        libpng
        libpng12
        libsamplerate
        libmikmod
        libtheora
        libtiff
        pixman
        speex
        SDL_image
        SDL_ttf
        SDL_mixer
        SDL2_ttf
        SDL2_mixer
        libappindicator-gtk2
        libdbusmenu-gtk2
        libindicator-gtk2
        libcaca
        libcanberra
        libgcrypt
        libvpx
        librsvg
        xorg.libXft
        libvdpau
        gnome2.pango
        cairo
        atk
        gdk-pixbuf
        fontconfig
        freetype
        dbus
        alsaLib
        expat
      ];
      NIX_LD = lib.fileContents "${pkgs.stdenv.cc}/nix-support/dynamic-linker";
  };  

You can also find the name of the libraries, see above nix-index. You can also use nix-alien-ld or nix-autobahn to automatically find and load the libraries for you. Note that if you don't have the right libraries you will get an error like

$ ./blender
./blender: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory

You can see at once all the libraries that are not yet available using:

$ LD_LIBRARY_PATH=$NIX_LD_LIBRARY_PATH ldd turtl
        libpangocairo-1.0.so.0 => /nix/store/n9h110ffps25rdkkim5k802p3p5w476m-pango-1.50.6/lib/libpangocairo-1.0.so.0 (0x00007f02feb83000)
        libatk-1.0.so.0 => not found
…

Method 9) nix-alien

nix-alien automatically builds a FHS with the appropriates libraries. If you have flake enabled (otherwise just add replace nix run with nix --extra-experimental-features "nix-command flakes" run) you can simply run it this way (nix-alien is not yet packaged in 2022)

nix run github:thiagokokada/nix-alien -- yourprogram

It will then automatically find the library using nix-index, asking you some questions when it is not sure (this is cached).

Note that programs that rely on openGl need to use nixGl to run (this certainly apply to other methods here):

nix run --impure github:guibou/nixGL --override-input nixpkgs nixpkgs/nixos-21.11 -- nix run github:thiagokokada/nix-alien -- blender

Note that you may need to change the version of nixos-21.11 to ensure that the version of openGl matches your program.

Note that you can also see the automatically generated file (the path is given the first time the program is run):

$ cat /home/leo/.cache/nix-alien/87a5d119-f810-5222-9b47-4809257c60ec/fhs-env/default.nix
{ pkgs ? import <nixpkgs> { } }:

let
  inherit (pkgs) buildFHSUserEnv;
in
buildFHSUserEnv {
  name = "blender-fhs";
  targetPkgs = p: with p; [
    xorg.libX11.out
    xorg.libXfixes.out
    xorg.libXi.out
    xorg.libXrender.out
    xorg.libXxf86vm.out
    xorg_sys_opengl.out
  ];
  runScript = "/tmp/blender-3.2.2-linux-x64/blender";
}

See also the other version working with nix-ld and nix-autobahn.

Method 9) Using containers/Docker (heavier)

TODO

Note that the project distrobox allows you to simply create new containers tightly integrated with the host installing any distribution you want.

Method 10) Rely on flatpack/appimage

https://nixos.org/nixos/manual/index.html#module-services-flatpak

appimage-run : To test with, ex, musescore

Sources or examples

• https://github.com/NixOS/nixpkgs/blob/5a9eaf02ae3c6403ce6f23d33ae569be3f9ce644/pkgs/applications/video/lightworks/default.nix
• https://sandervanderburg.blogspot.com/2015/10/deploying-prebuilt-binary-software-with.html
• https://github.com/NixOS/nixpkgs/blob/35c3396f41ec73c5e968a11f46d79a94db4042d7/pkgs/applications/networking/dropbox/default.nix

Also, for people wanting to get started in packaging, I wrote recently a similar tutorial here.