Created attachment 144009 [details] libgcrypt-1.6.1.diff - Update to 1.6.1 - Remove some unneeded patches - Fix pkg-plist Port maintainer is CC'd
Please check and approve.
It does not build on amd64, see http://lists.freebsd.org/pipermail/freebsd-ports/2014-July/093767.html
Tested on i386 (10.0-REL), builds there. So it's a amd64 specific issue because cipher/cast5-amd64.S is not linked to the build, somehow.
created https://bugs.g10code.com/gnupg/issue1668 upstream for libgcrypt
Patch: http://people.freebsd.org/~pi/misc/libgcrypt.svndiff build log: http://people.freebsd.org/~pi/misc/libgcrypt-1.6.1.log Still open: How to handle the lib.so bump
Created attachment 144455 [details] libgcrypt-1.6.1.diff Due to some build errors with MPI library, I added some patches to fix MPIs on i386 build log: http://pastebin.com/MEzAwn9h Now it compiles as expected.
(In reply to Kurt Jaeger from comment #5) > Patch: > > http://people.freebsd.org/~pi/misc/libgcrypt.svndiff > > > build log: > > http://people.freebsd.org/~pi/misc/libgcrypt-1.6.1.log > > > Still open: How to handle the lib.so bump See the following entry on /usr/ports/UPDATING % pkg updating -d 20130503
I simplify using REINPLACE_CMD on post-patch: diff -urN Makefile.orig Makefile --- Makefile.orig 2014-07-06 18:28:27.000000000 +0200 +++ Makefile 2014-07-06 18:24:02.000000000 +0200 @@ -40,6 +40,8 @@ post-patch: @${RM} -f ${WRKSRC}/doc/gcrypt.info* + @${REINPLACE_CMD} -e 's|ALIGN (3)|ALIGN (2)|g' \ + ${WRKSRC}/mpi/i386/*.S .if ${PORT_OPTIONS:MDOCS} post-install:
Created attachment 144465 [details] libgcrypt-1.6.1.diff
There's a prepared full diff at http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v3 and a list of affected ports at http://people.freebsd.org/~pi/misc/libgcrypt-related-ports Can we please have an exp-run to test that this works out OK ?
(In reply to Kurt Jaeger from comment #10) > There's a prepared full diff at > > http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v3 > > and a list of affected ports at > > http://people.freebsd.org/~pi/misc/libgcrypt-related-ports > > Can we please have an exp-run to test that this works out OK ? bdrewery@ could take it for exp-run :)
Take for exp-run Hello Kurt, Can you provide a patch against current head? Thanks!
Also it doesn't compile on 8amd64: https://redports.org//~antoine/20140723140000-33643-226850/libgcrypt-1.6.1.log
New svndiff, against head: http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v6 It also fixes the build on 8.4 amd64, see http://people.freebsd.org/~pi/misc/libgcrypt-1.6.1.log-84-amd64 Thanks for the exp-run!
Hi, It looks like: - the plist change for libgcrypt is missing in the patch - INSTALL_TARGET=install-strip should be preferred over ${STRIP} conditionned on DOCS option - USE_GCC=4.7 should be replaced by USE_GCC=yes, version 4.7 is retired upstream and we plan to move to 4.8 soon
New svndiff, against head: http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v7
Exp-run results: http://package22.nyi.freebsd.org/build.html?mastername=91amd64-default-PR191256&build=2014-07-24_07h18m10s 4 new failures: + {"origin"=>"devel/ccrtp", "pkgname"=>"ccrtp-2.0.6_4", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"editors/abiword", "pkgname"=>"abiword-2.8.6_5", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"security/p5-Crypt-GCrypt", "pkgname"=>"p5-Crypt-GCrypt-1.26_1", "phase"=>"build", "errortype"=>"compiler_error"} + {"origin"=>"security/shishi", "pkgname"=>"shishi-1.0.2_5", "phase"=>"configure", "errortype"=>"configure_error"} Failure logs: http://package22.nyi.freebsd.org/data/91amd64-default-PR191256/2014-07-24_07h18m10s/logs/errors/ccrtp-2.0.6_4.log http://package22.nyi.freebsd.org/data/91amd64-default-PR191256/2014-07-24_07h18m10s/logs/errors/abiword-2.8.6_5.log http://package22.nyi.freebsd.org/data/91amd64-default-PR191256/2014-07-24_07h18m10s/logs/errors/p5-Crypt-GCrypt-1.26_1.log http://package22.nyi.freebsd.org/data/91amd64-default-PR191256/2014-07-24_07h18m10s/logs/errors/shishi-1.0.2_5.log
Fixes for the additional ports see devel/ccrtp, PR 192162 editors/abiword, PR 192163 security/shishi, PR 192164 security/p5-Crypt-GCrypt, PR 192166 Do you want to wait for those to be committed for another exp-run ?
Hi, I confirm the patches fix: - shishi - p5-crypt-gcrypt - abiword However, I still get the same error with ccrtp.
Created attachment 145057 [details] patch to fix devel/ccrtp build, to apply to libgcrypt/files/ Thanks, I missed the test on 9.1, only did it on 10.0 8-( The attached patch for libgcrypt fixes this. This file needs to be placed in security/libgcrypt/files/ as patch-gcrypt.h.in
ok works fine now :)
Thanks for the heads-up! Does that mean that I'm clear to commit ? Inquiring minds want to know 8-)
Yes, and please add a note to UPDATING for portmaster or portupgrade users.
Committed in r363436, waiting 2 days for issues that might pop up.
And here am I :) I am a user of security/vpnc and after last update vpnc crashes after start: Core was generated by `vpnc'. Program terminated with signal 4, Illegal instruction. Reading symbols from /lib/libcrypto.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.7 Reading symbols from /usr/local/lib/libgcrypt.so.20...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgcrypt.so.20 Reading symbols from /usr/local/lib/libgpg-error.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgpg-error.so.0 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libintl.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800cc856a in _gcry_sha1_transform_amd64_ssse3 () from /usr/local/lib/libgcrypt.so.20 Setting USE_GCC=any at the security/libgcrypt/Makefile fixes everything for me, I don't even need to rebuild vpnc. # cc -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.0 Thread model: posix Selected GCC installation: # uname -a FreeBSD limbo.b1t.lan 10.0-STABLE FreeBSD 10.0-STABLE #34 r269300M: Wed Jul 30 12:57:16 EEST 2014 arcade@limbo.b1t.lan:/usr/obj/usr/src/sys/MINIMAL amd64 I also have CPUTYPE?=native at /etc/make.conf. My CPU is: CPU: AMD A8-5500 APU with Radeon(tm) HD Graphics (3200.08-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x610f01 Family = 0x15 Model = 0x10 Stepping = 1 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C> AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> AMD Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC> Structured Extended Features=0x8<BMI1> TSC: P-state invariant, performance statistics
Hi, When you run "make regression-test" from security/libgcrypt with clang, do the test succeed?
(In reply to Antoine Brodin from comment #26) > Hi, > > When you run "make regression-test" from security/libgcrypt with clang, do > the test succeed? I'm testing right now on 10.0: PASS: bench-slope SKIP: hashtest-256g ==================== All 24 tests passed (1 test was not run) ====================
(In reply to arcade from comment #25) > And here am I :) > > I am a user of security/vpnc and after last update vpnc crashes after start: Thanks, I'll investigate this.
I suggest, to avoid larger breakage: PORTREVISION up and USE_GCC for all archs ?
PASS: bench-slope SKIP: hashtest-256g ====================================== 10 of 24 tests failed (1 test was not run) Please report to http://bugs.gnupg.org ====================================== Same without CPUTYPE setting. Looks like something is about AMD, amd64 and clang. Yes I think using GCC for all archs would be fine.
I updated and rebuilt all ports installed which depend on libgcrypt. Only I can say that it went pretty well. % uname -a FreeBSD box.underbuild.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r268969: Tue Jul 22 12:50:29 CEST 2014 charly@box.underbuild.com:/usr/obj/usr/src/sys/PROD i386 % sudo cat /var/log/portmaster.log | tail -n 20 miércoles, 30 de julio de 2014, 12:57:28 CEST Upgrade of pkg-1.3.2 to pkg-1.3.3 Upgrade of libgcrypt-1.5.3_3 to libgcrypt-1.6.1 Upgrade of libxslt-1.1.28_3 to libxslt-1.1.28_4 Upgrade of pcre-8.34_1 to pcre-8.34_2 Re-installation of libgnome-keyring-2.32.0_8 Re-installation of gnome-keyring-2.32.1_4 Upgrade of pinentry-0.8.3 to pinentry-0.8.3_1 Upgrade of gnutls-3.2.16_2 to gnutls-3.2.16_3 Upgrade of glib-networking-2.36.2_3 to glib-networking-2.36.2_4 Upgrade of libsoup-2.40.3_5 to libsoup-2.40.3_6 Re-installation of libsoup-gnome-2.40.3_4 Upgrade of gvfs-1.12.3_3 to gvfs-1.12.3_4 Upgrade of libmatekeyring-1.6.0_1 to libmatekeyring-1.6.0_2 Re-installation of libgda4-4.2.12_3 Re-installation of gnupg-2.0.25_1 Re-installation of mate-keyring-1.6.0_2
(In reply to arcade from comment #25) > And here am I :) > > I am a user of security/vpnc and after last update vpnc crashes after start: Thanks for the report. I tested it here, and it worked. Now let's find a cause. > # cc -v > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Target: x86_64-unknown-freebsd10.0 > Thread model: posix # cc -v FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: x86_64-unknown-freebsd10.0 Thread model: posix > # uname -a > FreeBSD limbo.b1t.lan 10.0-STABLE FreeBSD 10.0-STABLE #34 r269300M: Wed Jul > 30 12:57:16 EEST 2014 arcade@limbo.b1t.lan:/usr/obj/usr/src/sys/MINIMAL > amd64 FreeBSD f10.opsec.eu 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun 3 13:14:57 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Are you familiar with gdb debugging ?
(In reply to Carlos Jacobo Puga Medina from comment #31) > I updated and rebuilt all ports installed which depend on libgcrypt. Only I > can say that it went pretty well. Can you test if vpnc starts ?
(In reply to arcade from comment #25) > And here am I :) > > I am a user of security/vpnc and after last update vpnc crashes after start: Can you build security/vpnc in poudriere on 10.0p7-amd64-REL ? And try whether the binary crashes as well ? Antoine suggested that you put your two WRKDIRs as .tgz somewhere and we compare it to our builds ?
(In reply to Kurt Jaeger from comment #33) > (In reply to Carlos Jacobo Puga Medina from comment #31) > > I updated and rebuilt all ports installed which depend on libgcrypt. Only I > > can say that it went pretty well. > > Can you test if vpnc starts ? I missing one that I'm just building...chromium and it goes well.
Yes, a tgz of security/libgcrypt/work when build with gcc + when build with clang could help
I archived both WRKDIR's at http://limbo.xim.bz/libgcrypt/ Whether it's relevant or not I'm using WRKDIRPREFIX:=/tmp/ports No, I have no gdb experience... but I can get on IRC :) Now I'll try building libgcrypt at some 10-RELEASE machine, right?
Well, I tried to test this on a number of machines. Everything works on the machines with Intel processors whether it's 10-RELEASE or 10-STABLE. Everything brakes when it's AMD running on 10-STABLE. I did a clean build, I don't use ccache for world and it still doesn't work. I'll try to install 10-RELEASE somewhere into the jail to test how 10-RELEASE works with AMD processors.
So, on a problematic AMD box could you: - install devel/gdb - build security/libgcrypt with clang - go to /tmp/ports/usr/ports/security/libgcrypt/work/libgcrypt-1.6.1/tests - verify that some programs there like ./basic do crash due to Illegal instruction - run /usr/local/bin/gdb ./basic In the gdb prompt, type run, type bt, type disass and enter until you reach the end of the function And copy all the output somewhere; that way we will see what is the illegal instruction
Installing devel/gdb. Meanwhile I already copied /usr/obj and /usr/src from one of the working machines and created a jail with 10-RELEASE. And the tests do fail: FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: x86_64-unknown-freebsd10.0 Thread model: posix
http://limbo.xim.bz/libgcrypt/libgcrypt.gdb.out Now it looks obvious: RdRand is an Intel instruction and doesn't exist in AMD chips.
(In reply to arcade from comment #41) > http://limbo.xim.bz/libgcrypt/libgcrypt.gdb.out > > Now it looks obvious: RdRand is an Intel instruction and doesn't exist in > AMD chips. Thanks, very cool that you found the cause. I have an AMD system to test this. Probably --disable-drng-support will help.
I have a system using an AMD chip: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.18-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Family = 0xf Model = 0x4b Stepping = 2 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x2001<SSE3,CX16> AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!> AMD Features2=0x1f<LAHF,CMP,SVM,ExtAPIC,CR8> Should I assume that I cannot build libgcrypt ohn this system?
(In reply to Gerard Seibert from comment #43) > I have a system using an AMD chip: [...] > Should I assume that I cannot build libgcrypt ohn this system? You can build it, but programs using it will probably not work. Please test and confirm. If you add CONFIGURE_ARGS+= --disable-drng-support to the ports makefile, and build it, do programms work ?
(In reply to Kurt Jaeger from comment #44) > (In reply to Gerard Seibert from comment #43) > > I have a system using an AMD chip: > [...] > > Should I assume that I cannot build libgcrypt ohn this system? > > You can build it, but programs using it will probably not work. > Please test and confirm. > > If you add > > CONFIGURE_ARGS+= --disable-drng-support > > to the ports makefile, and build it, do programms work ? I placed it here: .elif ${ARCH} == "amd64" .if (${OSVERSION} < 900000) USE_GCC= yes CONFIGURE_ARGS+= --disable-drng-support .endif Is that correct?
> > If you add > > > > CONFIGURE_ARGS+= --disable-drng-support > > > > to the ports makefile, and build it, do programms work ? > > I placed it here: > > .elif ${ARCH} == "amd64" > .if (${OSVERSION} < 900000) > USE_GCC= yes > CONFIGURE_ARGS+= --disable-drng-support > .endif > > Is that correct? Almost correct: Below this .endif, because it applies to all amd64 versions, not only those below 900000.
> Below this .endif, because it applies to all amd64 versions, not only > those below 900000. Tested, the fix works, I'll commit it.
A commit references this bug: Author: pi Date: Thu Jul 31 18:30:52 UTC 2014 New revision: 363648 URL: http://svnweb.freebsd.org/changeset/ports/363648 Log: security/libgcrypt: avoid non-portable use of assembler instruction on amd64 PR: 191256 Submitted by: arcade@b1t.name Changes: head/security/libgcrypt/Makefile
If other issues pop up, please open a new PR. This one is too long 8-)