I have a line CPUTYPE?=i686 in my /etc/make.conf, and, trying to upgrade pwlib-1.9.2_4,1 to 1.10.0,1, I got the following: g++ -O1 -I/usr/home/portsworkdir/usr/ports/devel/pwlib/work/pwlib_v1_10_0/includ e -I/usr/local/include -DP_USE_PRAGMA -D_REENTRANT -pthread -Wall -g -D_DEBUG -DNDEBUG -I/usr/home/portsworkdir/usr/ports/devel/pwlib/work/pwlib_v1_10_0/inclu de -O2 -fno-strict-aliasing -pipe -march=pentiumpro -O1 -I/usr/home/portsworkdi r/usr/ports/devel/pwlib/work/pwlib_v1_10_0/include -I/usr/local/include -felide -constructors -Wreorder -c ../common/jidctflt.cxx -o /usr/home/portsworkdir/usr/ ports/devel/pwlib/work/pwlib_v1_10_0/lib/obj_d/jidctflt.o {standard input}: Assembler messages: {standard input}:370: Error: suffix or operands invalid for `sar' {standard input}:397: Error: suffix or operands invalid for `sar' {standard input}:425: Error: suffix or operands invalid for `sar' {standard input}:454: Error: suffix or operands invalid for `sar' {standard input}:482: Error: suffix or operands invalid for `sar' {standard input}:510: Error: suffix or operands invalid for `sar' {standard input}:538: Error: suffix or operands invalid for `sar' {standard input}:566: Error: suffix or operands invalid for `sar' gmake[3]: *** [/usr/home/portsworkdir/usr/ports/devel/pwlib/work/pwlib_v1_10_0/lib/obj_d/jidctflt.o] Ошибка 1 gmake[3]: Leaving directory `/usr/home/portsworkdir/usr/ports/devel/pwlib/work/pwlib_v1_10_0/src/ptlib/unix' gmake[2]: *** [debug] Ошибка 2 gmake[2]: Leaving directory `/usr/home/portsworkdir/usr/ports/devel/pwlib/work/pwlib_v1_10_0' Fix: Either completely disable assembler snippet in question (port already disables it for x86_64 !), or add the following patch: How-To-Repeat: Compile the port for i686.
State Changed From-To: open->feedback Awaiting maintainers feedback
On Thu, Apr 06, 2006 at 11:24:47AM +0000, Edwin Groothuis wrote: > > The full text of the PR can be found at: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/95400 Kostik Belousov, Thank you for spotting this. As you noted that assembler snipped is already disabled for x86_64 (for the same reasons and errors you pointed out). I'm afraid my assembler-fu is not up to the task of evaluating of your correction is correct. If it is correct then I'm OK with submitting the change to the assembler especially if it also fixes the x86_64 case. However if the assembler cannot be confirmed I'd prefer we just patch jidctflt.cxx so that it always skips that assembler for all architectures. -steve
On Thu, Apr 06, 2006 at 10:38:37AM -0400, Steve Ames wrote: > On Thu, Apr 06, 2006 at 11:24:47AM +0000, Edwin Groothuis wrote: > > > > The full text of the PR can be found at: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/95400 > > Kostik Belousov, > > Thank you for spotting this. As you noted that assembler snipped is > already disabled for x86_64 (for the same reasons and errors you pointed > out). I'm afraid my assembler-fu is not up to the task of evaluating of > your correction is correct. If it is correct then I'm OK with submitting > the change to the assembler especially if it also fixes the x86_64 case. I don't have access to the x86_64 machine and don't have time to build a cross-compiler, so, I cannot check whether change would work for that arch. > > However if the assembler cannot be confirmed I'd prefer we just patch > jidctflt.cxx so that it always skips that assembler for all architectures. See, I can't test the code. It looks like openh323 developers did not compile it either. The problem is that sar instruction (shift arithmetical right) requires shift count to be supplied in register %cl. Constraint supplied allows for shift count to be put in any register. If the code compiles on the developers machine, it was by pure coincident. Because of this, I propose to disable the code uncoditionally.
Kostik Belousov wrote: > On Thu, Apr 06, 2006 at 10:38:37AM -0400, Steve Ames wrote: > See, I can't test the code. It looks like openh323 developers did not > compile it either. The problem is that sar instruction (shift > arithmetical right) requires shift count to be supplied in register > %cl. Constraint supplied allows for shift count to be put in any > register. If the code compiles on the developers machine, it was by > pure coincident. > > Because of this, I propose to disable the code uncoditionally. Agreed. This file was added new in 1.10.0 to support MJPEG streams from some webcams. Complete disabling is probably the way to go. Patch follows: ----------------------------------- --- files/patch-src_ptlib_common_jidctflt.cxx.orig Thu Apr 6 11:29:07 2006 +++ files/patch-src_ptlib_common_jidctflt.cxx Thu Apr 6 11:31:02 2006 @@ -1,11 +1,12 @@ --- src/ptlib/common/jidctflt.cxx.orig Wed Apr 5 07:08:00 2006 +++ src/ptlib/common/jidctflt.cxx Wed Apr 5 07:08:08 2006 -@@ -80,7 +80,7 @@ +@@ -80,7 +80,8 @@ #define DEQUANTIZE(coef,quantval) (((FAST_FLOAT) (coef)) * (quantval)) -#if defined(__GNUC__) && (defined(__i686__) || defined(__x86_64__)) -+#if defined(__GNUC__) && defined(__i686__) ++/* asm doesn't compile properly... avoid using */ ++#if 0 static inline unsigned char descale_and_clamp(int x, int shift) { ---------------------------------------
Approved. I had approved earlier but from my other email address.
State Changed From-To: feedback->open Maintainer approved.
State Changed From-To: open->closed Committed, thanks! Please do not forget to bug pwlib authors.