sys-fs/cryptsetup-1.6.4 (gcrypt nls static) + dev-libs/libcrypt-1.6.1 (static-libs) seem to exhibit a linking failure on my system. The problem only shows during luksFormat, luckily not during luksOpen. (gdb) set args luksFormat --cipher aes-xts-plain --key-size 256 /dev/sdd2 (gdb) run Starting program: /sbin/cryptsetup luksFormat --cipher aes-xts-plain --key-size 256 /dev/sdd2 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". WARNING! ======== This will overwrite data on /dev/sdd2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x000000000042cc27 in _gcry_ath_mutex_init () #2 0x000000000043fb00 in _gcry_primegen_init () #3 0x00000000004262b5 in global_init.part () #4 0x00000000004264bd in _gcry_check_version () #5 0x0000000000413b0c in crypt_backend_init () #6 0x000000000040972c in init_crypto () #7 0x000000000040ca57 in crypt_format () #8 0x0000000000407f09 in action_luksFormat () #9 0x0000000000403532 in main () disassembly of the function shows (gdb) disass 0x42cc10,0x42cc27 Dump of assembler code from 0x42cc10 to 0x42cc27: 0x000000000042cc10 <_gcry_ath_mutex_init+32>: callq 0x51b620 <malloc> 0x000000000042cc15 <_gcry_ath_mutex_init+37>: test %rax,%rax 0x000000000042cc18 <_gcry_ath_mutex_init+40>: mov %rax,%rbp 0x000000000042cc1b <_gcry_ath_mutex_init+43>: je 0x42cc60 <_gcry_ath_mutex_init+112> 0x000000000042cc1d <_gcry_ath_mutex_init+45>: xor %esi,%esi 0x000000000042cc1f <_gcry_ath_mutex_init+47>: mov %rax,%rdi 0x000000000042cc22 <_gcry_ath_mutex_init+50>: callq 0x0 0x000000000042cc27 <_gcry_ath_mutex_init+55>: test %eax,%eax With the matching code in libgcrypt-1.6.1/src/ath.c ath_mutex_init (ath_mutex_t *lock) { ... plck = malloc (sizeof *plck); if (!plck) err = errno? errno : ENOMEM; else { err = pthread_mutex_init (plck, NULL); if (err) ... I can only assume the call to 0x0 instead of pthread_mutex_init comes from here: /* On an ELF system it is easy to use pthreads using weak references. Take care not to test the address of a weak referenced function we actually use; some GCC versions have a bug were &foo != NULL is always evaluated to true in PIC mode. USING_PTHREAD_AS_DEFAULT is used by ath_install to detect the default usage of pthread. */ #if USE_POSIX_THREADS_WEAK # pragma weak pthread_cancel # pragma weak pthread_mutex_init # pragma weak pthread_mutex_lock # pragma weak pthread_mutex_unlock # pragma weak pthread_mutex_destroy #endif and those weak references are not resolved either during static linking of libgcrypt.a or the final linking of the cryptsetup binary. Removing the weak threads symbol causes a hard dependency on pthreads, which is not reflected in /usr/bin/libgcrypt-config --libs output. Reproducible: Always There are apparently two solutions. a) Make libgcrypt hard-depend on pthreads, by adding sed -i 's/#define USE_POSIX_THREADS_WEAK 1//' ${S}_build/config.h sed -i 's/libs="-lgcrypt"/libs="-lgcrypt -lpthread"/' ${S}_build/src/libgcrypt-config to the src_configure section of the ebuild (tested and working here atm). Maybe the second line alone works already, not sure. b) force -lpthread into cryptsetup, and potentially other users of static libgcrypt (untested)
*** This bug has been marked as a duplicate of bug 496612 ***