security/cryptopp fails to build. It seems to be an intermittent problem affecting very few users with no apparent correlation. I get messages like: {standard input}: Assembler messages: {standard input}:343: Error: no such instruction: `palignr xmm5,xmm2,4' {standard input}:343: Error: no such instruction: `palignr xmm6,xmm3,4' {standard input}:349: Error: no such instruction: `palignr xmm7,xmm3,4' {standard input}:349: Error: no such instruction: `palignr xmm6,xmm2,4' {standard input}:349: Error: no such instruction: `palignr xmm5,xmm1,4' {standard input}:349: Error: no such instruction: `palignr xmm4,xmm0,4' Fix: I think adding -DCRYPTOPP_DISABLE_SSSE3 to CXXFLAGS ameliorates the problem, but it doesn't explain why the assembler would somehow end up getting instructions it can't assemble. Also, the processor definitely supports SSSE3. How-To-Repeat: Attempt to compile the latest cryptopp from ports. It is unknown what other factors are necessary to induce this bug. If it helps, the processor in question is a Xeon E5335 which does have support for the instruction. It also doesn't happen on a similarly-configured machine with a different processor, which somehow adds -DCRYPTOPP_DISABLE_SSSE3 to its CXXFLAGS. I'm using gcc 4.2.1 and FreeBSD 8.1-RELEASE-p2 on both machines.
Responsible Changed From-To: freebsd-ports-bugs->delphij Over to maintainer (via the GNATS Auto Assign Tool)
Chris Tandiono <christandiono@tbp.berkeley.edu> writes: > {standard input}: Assembler messages: > {standard input}:343: Error: no such instruction: `palignr xmm5,xmm2,4' > {standard input}:343: Error: no such instruction: `palignr xmm6,xmm3,4' > {standard input}:349: Error: no such instruction: `palignr xmm7,xmm3,4' > {standard input}:349: Error: no such instruction: `palignr xmm6,xmm2,4' > {standard input}:349: Error: no such instruction: `palignr xmm5,xmm1,4' > {standard input}:349: Error: no such instruction: `palignr xmm4,xmm0,4' as(1) in base doesn't have SSE3 support. The port blindly assumes the first as(1) found in PATH as the one gcc(1) would use ignoring COMPILER_PATH and default being /usr/bin. $ env -i PATH=/usr/local/bin:/usr/bin as -v -o/dev/null -</dev/null GNU assembler version 2.21 (x86_64-portbld-freebsd9.0) using BFD version (GNU Binutils) 2.21 $ env -i PATH=/usr/local/bin:/usr/bin gcc -print-search-dirs install: /usr/libexec/ programs: =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ libraries: =/usr/lib/:/usr/lib/ $ env -i COMPILER_PATH=/usr/local/bin gcc -print-search-dirs install: /usr/libexec/ programs: =/usr/local/bin/:/usr/local/bin/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ libraries: =/usr/lib/:/usr/lib/ Does the patch below solve the issue? --- a.diff begins here --- Index: security/cryptopp/files/patch-GNUmakefile =================================================================== RCS file: /a/.cvsup/ports/security/cryptopp/files/patch-GNUmakefile,v retrieving revision 1.1 diff -u -p -r1.1 patch-GNUmakefile --- security/cryptopp/files/patch-GNUmakefile 27 Mar 2009 00:02:32 -0000 1.1 +++ security/cryptopp/files/patch-GNUmakefile 27 Jan 2011 07:10:48 -0000 @@ -6,3 +6,16 @@ #CXXFLAGS = -g # -fPIC is supported. Please report any breakage of -fPIC as a bug. # CXXFLAGS += -fPIC +@@ -28,9 +28,9 @@ GCC42_OR_LATER = $(shell $(CXX) -v 2>&1 + INTEL_COMPILER = $(shell $(CXX) --version 2>&1 | $(EGREP) -c "\(ICC\)") + ICC111_OR_LATER = $(shell $(CXX) --version 2>&1 | $(EGREP) -c "\(ICC\) ([2-9][0-9]|1[2-9]|11\.[1-9])") + IS_SUN_CC = $(shell $(CXX) -V 2>&1 | $(EGREP) -c "CC: Sun") +-GAS210_OR_LATER = $(shell echo "" | $(AS) -v 2>&1 | $(EGREP) -c "GNU assembler version (2\.[1-9][0-9]|[3-9])") +-GAS217_OR_LATER = $(shell echo "" | $(AS) -v 2>&1 | $(EGREP) -c "GNU assembler version (2\.1[7-9]|2\.[2-9]|[3-9])") +-GAS219_OR_LATER = $(shell echo "" | $(AS) -v 2>&1 | $(EGREP) -c "GNU assembler version (2\.19|2\.[2-9]|[3-9])") ++GAS210_OR_LATER = $(shell echo "" | $(CXX) -xc -c -Wa,-v -o/dev/null - 2>&1 | $(EGREP) -c "GNU assembler version (2\.[1-9][0-9]|[3-9])") ++GAS217_OR_LATER = $(shell echo "" | $(CXX) -xc -c -Wa,-v -o/dev/null - 2>&1 | $(EGREP) -c "GNU assembler version (2\.1[7-9]|2\.[2-9]|[3-9])") ++GAS219_OR_LATER = $(shell echo "" | $(CXX) -xc -c -Wa,-v -o/dev/null - 2>&1 | $(EGREP) -c "GNU assembler version (2\.19|2\.[2-9]|[3-9])") + ISMINGW = $(shell $(CXX) --version 2>&1 | $(EGREP) -c "mingw") + + ifneq ($(GCC42_OR_LATER),0) --- a.diff ends here ---
On Wed, 26 Jan 2011 23:23:09 -0800, Anonymous <swell.k@gmail.com> wrote: > Chris Tandiono <christandiono@tbp.berkeley.edu> writes: > >> {standard input}: Assembler messages: >> {standard input}:343: Error: no such instruction: `palignr xmm5,xmm2,4' >> {standard input}:343: Error: no such instruction: `palignr xmm6,xmm3,4' >> {standard input}:349: Error: no such instruction: `palignr xmm7,xmm3,4' >> {standard input}:349: Error: no such instruction: `palignr xmm6,xmm2,4' >> {standard input}:349: Error: no such instruction: `palignr xmm5,xmm1,4' >> {standard input}:349: Error: no such instruction: `palignr xmm4,xmm0,4' > > as(1) in base doesn't have SSE3 support. The port blindly assumes the > first as(1) found in PATH as the one gcc(1) would use ignoring > COMPILER_PATH and default being /usr/bin. > > $ env -i PATH=/usr/local/bin:/usr/bin as -v -o/dev/null -</dev/null > GNU assembler version 2.21 (x86_64-portbld-freebsd9.0) using BFD > version (GNU Binutils) 2.21 > > $ env -i PATH=/usr/local/bin:/usr/bin gcc -print-search-dirs > install: /usr/libexec/ > programs: > =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ > libraries: =/usr/lib/:/usr/lib/ > > $ env -i COMPILER_PATH=/usr/local/bin gcc -print-search-dirs > install: /usr/libexec/ > programs: > =/usr/local/bin/:/usr/local/bin/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ > libraries: =/usr/lib/:/usr/lib/ > > Does the patch below solve the issue? > > --- a.diff begins here --- > ... > --- a.diff ends here --- lgtm. Compiles and installs fine. -- Chris Tandiono
delphij 2011-01-27 20:47:30 UTC FreeBSD ports repository Modified files: security/cryptopp/files patch-GNUmakefile Log: crypto++ assumes that the as(1) in PATH is the one used by c++(1), which is not always true. When PATH is being configured to a non-standard sequence, we may found an as(1) newer than the base one and draw wrong conclusion which leads to failed builds. Use the result given by c++. This is also accepted to upstream. PR: ports/154325 Submitted by: swell.k gmail.com Feature safe: yes Revision Changes Path 1.2 +15 -2 ports/security/cryptopp/files/patch-GNUmakefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed A fix have been committed, thanks for your submission!