talon at lpthe.jussieu.fr
Sat Oct 11 15:59:48 UTC 2008
On Sun, Oct 12, 2008 at 12:42:08AM +1100, Sean Winn wrote:
> Another option is to just fix the configure script so it doesn't break on
> nasm > 1 (it's failing on the patch level check)
> The attached file dropped in ports/multimedia/xvid/files/ seems to do the
> trick, though I don't use xvid so I can't exactly test that the new version
> assembles things properly.
> Something done to configure.in should be sent upstream really.
Yes, fixing the configure script should be done upstream, but it
seems that the xvid project is somewhat asleep, so better use
yasm in the Makefile on which there is control. As you note below,
the problem comes because the configure script tries to use the -r
option which yasm has but not nasm, so the xvid people had really
yasm in view when doing their work.
> --- configure.orig 2008-10-11 13:40:34.000000000 +1100
> +++ configure 2008-10-11 13:43:14.000000000 +1100
> @@ -4016,7 +4016,12 @@
> if test "$ac_nasm" = "yes" ; then
> echo "$as_me:$LINENO: checking for nasm patch version" >&5
> echo $ECHO_N "checking for nasm patch version... $ECHO_C" >&6
> - nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1`
> + nasm_version=`$nasm_prog -v | cut -d '.' -f 1 | cut -d ' ' -f3`
> + if test -n "$nasm_version" -a "$nasm_version" -gt 1; then
> + nasm_patch=$minimum_nasm_patch_version
> + else
> + nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1`
> + fi
> if test -z $nasm_patch ; then
By the way, the performance improvement obtained by using SSE
instructions in the assembly files is astounding. I could not beleive
what i was seeing, basically an x 4 improvement, that is the code
perfectly parallelizes the computations on the 128 bits registers.
This is a good illustration of the fact that compilers are not always
as smart as people say, and assembly code can crush C code.
More information about the freebsd-ports