Since commit
7b9fd5d1c9
tsm-client no longer produces working binaries
(discovered with bisection).
Instead, calling the command line client `dsmc`
just produces the error
> error while loading shared libraries: libtsmxerces-depdom.so.28: cannot open shared object file: No such file or directory
Output of `ldd $out/dsmc`
> linux-vdso.so.1 (0x00007ffd89f70000)
> libgsk8ssl_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8ssl_64.so (0x0000791c8eb34000)
> libgsk8iccs_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8iccs_64.so (0x0000791c8e9b7000)
> libgsk8km_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8km_64.so (0x0000791c8e791000)
> libxmlutil-8.1.13.0.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/opt/tivoli/tsm/client/api/bin64/libxmlutil-8.1.13.0.so (0x0000791c8e675000)
> libcrypt.so.1 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libcrypt.so.1 (0x0000791c8e639000)
> libpthread.so.0 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0 (0x0000791c8e619000)
> libdl.so.2 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libdl.so.2 (0x0000791c8e614000)
> libstdc++.so.6 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x0000791c8e43f000)
> libgpfs.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/opt/tivoli/tsm/client/api/bin64/libgpfs.so (0x0000791c8e22a000)
> libdmapi.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/opt/tivoli/tsm/client/api/bin64/libdmapi.so (0x0000791c8e020000)
> librt.so.1 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/librt.so.1 (0x0000791c8e015000)
> libm.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libm.so.6 (0x0000791c8ded4000)
> libgcc_s.so.1 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x0000791c8deba000)
> libc.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6 (0x0000791c8dce5000)
> libgsk8cms_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8cms_64.so (0x0000791c8d78d000)
> /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/ld-linux-x86-64.so.2 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x0000791c8f074000)
> libtsmxerces-depdom.so.28 => not found
> libtsmxerces-c.so.28 => not found
Output of `ldd $out/lib/libtsmxerces-depdom.so.28`
> linux-vdso.so.1 (0x00007fff69388000)
> libpthread.so.0 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0 (0x000078f150454000)
> libtsmxerces-c.so.28 => not found
> libstdc++.so.6 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x000078f15027f000)
> libm.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libm.so.6 (0x000078f15013e000)
> libgcc_s.so.1 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x000078f150124000)
> libc.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6 (0x000078f14ff4d000)
> /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x000078f150601000)
The commit given above rewrote the `autoPatchelfHook`.
The new hook still calls `patchelf` to actually
modify binary files, but the discovery of
shared libraries apparently got changed.
Thorough investigation of all `patchelf` calls in the
old and new autoPatchelfHook showed that all files are
treated equally up the the files
* $out/opt/tivoli/tsm/client/api/bin64/libtsmxerces-depdom.so.28.0
* $out/opt/tivoli/tsm/client/api/bin64/libxmlutil-8.1.13.0.so
where the new autoPatchelf implementation replaced `$out/lib`
with `$out/opt/tivoli/tsm/client/api/bin64` in the rpath.
I failed to see *why* the new algorithm does
that, or if that might be considered a bug.
The `tsm-client` package has some confusing symlink
structure which certainly might confuse `autoPatchelfHook`.
The following ideas to "restore" the old behaviour
of `autoPatchelfHook` failed to produce a working package:
* add "$out" or "${placeholder "out"}" to `runtimeDependencies`
* use `addAutoPatchelfSearchPath` with `$out/lib` or
another so-file-containing directory
The commit at hand fixes the issue by directly adding `$out/lib`
to the rpath of all shared libraries in that directory.
This has to be done *after* `autoPatchelf` got executed.
To accomplish this, we disable auto-calling `autoPatchelf`
(it would run after `postFixup`) and instead call it
manually in `postFixup`, just before we patch the rpath by hand.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: xbstream.c.o:(.bss+0x0): multiple definition of
`datasink_buffer'; ds_buffer.c.o:(.data.rel.local+0x0): first defined here
pydrive is abandoned and has unfixed issues. In particular, Deja Dup
backups (which uses duplicity as backend) to Google Drive fail with
Giving up after 5 attempts. RedirectMissingLocation: Redirected but
the response is missing a Location: header.
More context and pointers are available in the Deja Dup bug tracker:
https://gitlab.gnome.org/World/deja-dup/-/issues/202#note_1306216
It seems that duplicity needs boto instead of boto3.
They apparently have different packages.
I decided to keep both,
as there may be another backend depending on it.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: listindex.o:/build/btar-1.1.1/loadindex.h:12: multiple definition of
`ptr'; main.o:/build/btar-1.1.1/loadindex.h:12: first defined here
These derivations use buildDotnetModule, which has had its default
dotnet version changed recently. This patch removes redundantly setting
the SDK/runtime to version 6.
