`tsm-client` is delivered with its
own `lib{crypto,ssl}.so` implementation.
Beginning with version 8.1.9.1, those `.so`-files came with
absolute symlinks to `/opt/...` causing `autoPatchelf`
to abort with error messages of the form
> error: auto-patchelf could not satisfy dependency libssl.so.1.1
I was under the impression that a new dependency
got introduced and added `openssl` to `builtInputs`
in commit 5ad0ecb901.
This fixed the build, but `tsm-client` no longer
linked against its own ssl implementation.
The commit at hand corrects that mistake:
It adds a small `preFixup` script that finds
and adapts absolute symlinks to `/opt/`,
so that `autoPatchelfHook` finds those
`so`-files again and sets RPATH properly.
This permits to drop `openssl` from the dependency list again.
Since commit 4e300e071b
building `tsm-client` fails with error messages
> error: auto-patchelf could not satisfy dependency libcrypt.so.1 wanted by [...]
Luckily, commit 9b766dd41b
introduces `libxcrypt-legacy` which again provides `libcrypt.so.1`.
The former packages has seen its last release in 2020-10 and can be
considered abandoned. Meanwhile a new fork has appeared in
faust-cchardet, that we're going to use in its place.
Co-Authored-By: Robert Schütz <nix@dotlambda.de>
due to 2e9f70d496
there is another "sleep", which is now wrongly substituted.
This fixes the error:
Failed to inhibit: Invalid what specification
/nix/store/if12v01xkqladifvk8yqjdpbp6sisg74-coreutils-9.1/bin/sleep:shutdown
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
It won't be enough to fix cross in all cases, but it is in at least
one: pywayland. I've only made the change in cases I'm confident it's
correct, as it would be wrong to change this when python.interpreter
is used in wrappers, and possibly when it's used for running tests.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
libiconv is already defined per-platform. The actual libiconv library
won't be built on platforms like Linux where it doesn't need to be, so
there's no need to maintain a separate platform list here.
Required to build for FreeBSD.
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
borgbackup/borg#7250 is now fixed in 1.2-maint (pending for borg 1.2.4)
but borgbackup/borg#7252 was amended to a different approach before
being apporoved. Replace the original workaround with upstream's fix.
Borg can use the python pkgconfig package to discover library paths, we
don't need to pass them explicitly.
Removes libb2, because borg since version 1.2.0 uses hashlib.blake2b
instead.
Error with LLVM stdenv on aarch64-darwin:
libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I../.. -DLIBDAR_MODE=64 -DDAR_LOCALEDIR=\"/nix/store/waclhq32gacp2010gyjx17f9h6xpsf8d-dar-2.7.7/share/locale\" -I/nix/store/1m4gsx4p4fl5xpg0h8splmwz7j2y3cbp-gpgme-1.18.0-dev/include -I/nix/store/fpc4g6ql1mx4na5rkjhik5f2wixymzhy-libassuan-2.5.5-dev/include -I/nix/store/qhznxypyfh3w5xdbxxd2n47d9c8jr2bx-libgpg-error-1.45-dev/include -g -O2 -c parallel_block_compressor.cpp -D__DYNAMIC__ -fno-common -DPIC -o .libs/parallel_block_compressor.o
In file included from parallel_tronconneuse.cpp:28:
In file included from ./parallel_tronconneuse.hpp:39:
In file included from /nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/string:506:
In file included from /nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/string_view:175:
In file included from /nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/__string:57:
In file included from /nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/algorithm:643:
/nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/memory:3455:7: error: exception specification of overriding function is more lax than base version
class __shared_ptr_emplace
^
/nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/memory:4291:26: note: in instantiation of template class 'std::__1::__shared_ptr_emplace<libthreadar::barrier, std::__1::allocator<libthreadar::barrier>>' requested here
::new(__hold2.get()) _CntrlBlk(__a2, _VSTD::forward<_Args>(__args)...);
^
parallel_tronconneuse.cpp:102:15: note: in instantiation of function template specialization 'std::__1::make_shared<libthreadar::barrier, unsigned long>' requested here
waiter = make_shared<barrier>(num_workers + 2); // +1 for crypto_reade thread, +1 this thread
^
/nix/store/3lsnbsiwzy2gzga1m2bszb7r9d6wraz2-libcxx-11.1.0-dev/include/c++/v1/memory:3364:13: note: overridden virtual function is here
virtual ~__shared_weak_count();
^
1 error generated.
make[3]: *** [Makefile:1383: parallel_tronconneuse.lo] Error 1
* Reorder `libevent` and `libev` in `buildInputs`. Otherwise, cmake
picks up the wrong `event.h` and the version test for `libevent`
fails.
* Remove apparently obsolete workaround from fc8061dae4.
- There is no need to pass pname and version arguments
- The version lister does not use positional arguments anymore, but
option arguments. Removed the echo command to fix an issue regarding
this.
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.
