Created attachment 378510 [details] emerge --info Hello, When trying to compile app-crypt/gnupg (version 2.0.22 or 2.0.23, exact same behavior), when dev-libs/libgcrypt-1.6.1-r1 is installed (I required this version because of my system under x32 profile and therefore the need of ABI_X86), app-crypt/gnupg will fail when it is testing if the compilation is correct (see the log): ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc gpg: signal Segmentation fault caught ... exiting When I do a strace of the above command, I can see this: /var/tmp/portage/app-crypt/gnupg-2.0.23/work/gnupg-2.0.23/tests/openpgp# strace ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc ../.. --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xf79fb000} --- ../.. Maybe the problem is from app-crypt/gnupg, and this bug is showing us a bug in its source code. Steps to Reproduce: 1. emerge libgcrypt with version >= 1.6.1-r1 2. re-emerge app-crypt/gnupg-2* Reproducible: Under x32 profile, always, but success on no-x32 profiles
Created attachment 378512 [details] build.log of app-crypt/gnupg-2.0.23 Build of the emerging app-crypt/gnupg-2.0.23, where we can see line 819 the test failure: In /var/tmp/portage/app-crypt/gnupg-2.0.23/work/gnupg-2.0.23/tests/openpgp: ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc gpg: signal Segmentation fault caught ... exiting
Created attachment 378514 [details] strace of the test during emerging app-crypt/gnupg-2.0.23 When emerging app-crypt/gnupg-2.0.23, the following command is executed, in /var/tmp/portage/app-crypt/gnupg-2.0.23/work/gnupg-2.0.23/tests/openpgp: ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc but the result is a segmentation fault: --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xf79fb000} ---
Any updates, please? I could do a coredump, but I am not very aware of "how to do", during a compilation.
Created attachment 381430 [details] config.log of app-crypt/gnupg-2.0.25 /var/tmp/portage/app-crypt/gnupg-2.0.25/work/gnupg-2.0.25/config.log
Created attachment 381434 [details] Diff to an ebuild for libcrypt which disable assembly code. Good news everyone! Thanks to K_F, he discovered the problem was related to assembly code. So he made an ebuild which disable asm, see attachment. Now app-crypt/gnupg can be compiled, and works (I didn't make a lot of test, but signing, cypehring and verifying are working). Thanks a lot.
So x86 is not working with asm and amd64 is? Or both fail?
(In reply to Alon Bar-Lev from comment #6) > So x86 is not working with asm and amd64 is? Or both fail? I am currently on x86_x32 (multilib), on my server with x86_64 (multilib), it works, but I didn't try with x86_32. So, to be clear, it works on 64 for sure, it works on x32 with --disable-asm, no idea with 32.
(In reply to Alon Bar-Lev from comment #6) > So x86 is not working with asm and amd64 is? Or both fail? I believe x86 works as well, amd64 certainly does - note that this is x32, I haven't done any debugging as to how the detection for it is actually done in libgcrypt. The ebuild was just a quick test to have the ability to flip asm on/off at will. It should definitely default to ON if a use flag is introduced for the behavior more generally. Alternatively disabling asm can be done for x32 similar to how it is done for darwin etc today.
disable asm is not the right solution, the root cause should be found and fixed. probably the asm code thinks it is in 64bit mode.
(In reply to Alon Bar-Lev from comment #9) > disable asm is not the right solution, the root cause should be found and > fixed. probably the asm code thinks it is in 64bit mode. Indeed, that is my guess as well.
For reference I found this in the archive http://comments.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2611 . Seems we don't currently carry the historical patch that would allow x32 to operate. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-x32.patch?hideattic=0&view=markup See also bug 427726
Some related bugs: bug 506672 bug 499338
Created attachment 381646 [details] gdb ../../g10/gpg2, with -O0 Providing the same informations than bug 499338 comment 3. Used -O0 when compiling.
Created attachment 381826 [details, diff] libgcrypt-1.6.1-x32-compat.patch Attaching a possible fix .
much better! :)
+*libgcrypt-1.6.1-r2 (29 Jul 2014) + + 29 Jul 2014; Kristian Fiskerstrand <k_f@gentoo.org> + +files/libgcrypt-1.6.1-x32-compat.patch, +libgcrypt-1.6.1-r2.ebuild: + Revbump to add patch to fix segfaults for x32 ABIs. Fixes bug #512762
please open upstream bug, and attach the patch. https://bugs.g10code.com/ attach bug url to this bug.
*** Bug 499338 has been marked as a duplicate of this bug. ***
(In reply to Alon Bar-Lev from comment #17) > please open upstream bug, and attach the patch. > > https://bugs.g10code.com/ > > attach bug url to this bug. Upstream bug: https://bugs.g10code.com/gnupg/issue1676
Created attachment 381834 [details] /var/tmp/portage/dev-libs/libgcrypt-1.6.1-r1/work/libgcrypt-1.6.1-abi_x86_x32.x32/config.log Adding config.log files. First the x32.
Created attachment 381836 [details] /var/tmp/portage/dev-libs/libgcrypt-1.6.1-r1/work/libgcrypt-1.6.1-abi_x86_64.amd64/config.log and here the amd64 version.
thanks! I think that indeed we should make the build system use the i585 in case of x32.
(In reply to Alon Bar-Lev from comment #22) > thanks! > > I think that indeed we should make the build system use the i585 in case of > x32. I'm not entirely sure that'd work, one reason being what is discussed re x32 in http://lists.x.org/archives/xorg-devel/2011-December/028164.html: "amd64 instruction set is not a superset of i386, otherwise __amd64__ would not exist at all. - amd64 can't address certain "small" register forms (like %bh) - can't encode many legacy instructions (decimal ones for example: DAA, DAS, etc.) - can't encode many prefixes (ES, SS overrides, etc.)." What is interesting is ""64-bit registers can be used to operate on pointers and unsigned long passed or returned in registers since the x32 calling conversion specifies pointers and unsigned long are zero-extended to 64 bits when passed or returned in registers. " from https://sourceware.org/glibc/wiki/x32 , which is the reason the current approach makes sense.
ok, I will wait for upstream response... sorry.
This patch is now included upstream http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a17c29844b63e9e869f7855d901bc9d859234ead
