How to deal with locally built shared libraries when packaging?


I am working on trying to package pcloudcc for Nix.

This is the current work in progress nix expression:

{ lib, stdenv, fetchFromGitHub, zlib, boost, fuse, cmake, systemdMinimal }:

stdenv.mkDerivation rec {
  pname = "pcloud-cli";
  version = "2.10";

  src = fetchFromGitHub {
    owner = "pcloudcom";
    repo = "console-client";
    rev = "2ecb7c981554499501f0a4f0512bd7a1a483645b";
    sha256 = "rYB3Tedne6Nrf/PJC1i+X6XgtoQ9/3neTiHwroAd90E=";

  doCheck = true;

  # TODO try to move as much as possible to nativeBuildInputs
  # TODO change systemdMinial to udev and if it breaks override it to be systemdMinimal
  # on callPackage (this is how it should be called when placed in nixpkgs)
  buildInputs = [ zlib boost fuse cmake systemdMinimal ];

  phases = [ "unpackPhase" "patchPhase" "buildPhase" "installPhase" ];

  patches = [ /tmp/static_off.patch ];

  buildPhase = ''
    pushd pCloudCC/
    pushd lib/pclsync/
    make clean
    make fs
    cd ../mbedtls/
    cmake .
    make clean
    cmake .

  installPhase = "cp pCloudCC/pcloudcc $out/bin/";

  meta = with lib; {
    description = "PCloud CLI client";
    homepage = "";
    changelog =
    license = licenses.gpl3Plus;
    maintainers = [ maintainers.eelco ];
    platforms = platforms.all;

The buildPhase was taken from the repository’s instructions on how to build the project.


diff --git a/pCloudCC/CMakeLists.txt b/pCloudCC/CMakeLists.txt
index 0d6b5c3..9879733 100644
--- a/pCloudCC/CMakeLists.txt
+++ b/pCloudCC/CMakeLists.txt
@@ -3,7 +3,7 @@ project(pcloudcc)

I stumbled upon this roadblock as the project builds a helper library during the build and then links to it for the final

If I build the project locally in nix-shell in
/tmp/nix-build-pcloud-cli-2.10.drv-0 for example I get this line with ldd: => /tmp/nix-build-pcloud-cli-2.10.drv-0/source/pCloudCC/

Needless to say this does not work when I use nix-build. The ldd output has: => not found

What would be the correct way to package these cases?

I thought of perhaps creating an inner derivation for for pcloudcc_lib and
then put it in the buildInputs for pcloudcc, however looking at the

CMakeFiles/pcloudcc.dir/all: CMakeFiles/pcloudcc_lib.dir/all

It looks like building pcloudcc causes building of pcloudcc_lib as well.

  • Is it the correct approach to have an inner derivation AND patch the source wherever necessary so that building pcloudcc will not cause pcloudcc_lib to be built?
  • Perhaps I am missing a much simpler way of fixing the reference?
  • Perhaps I should build normally and copy to $out/lib and wrap the executable with a script that invokes the executable with LD_LIBRARY_PATH set to $out/lib?

Thanks for the help!

Solved it. Posting about it in case it helps someone with a similar problem.

Apparently just adding the library .so to $out/lib made ldd on the executable find it!
Despite it not being used during compilation and not even setting LD_LIBRARY_PATH.

I am guessing that ldd has some logic to search for the .so in some certain relative paths to the binary so that putting the binary in $out/bin and the library in $out/lib makes it work.