multimedia/xvid

Carlos A. M. dos Santos unixmania at gmail.com
Mon Oct 13 04:37:57 UTC 2008


On Sat, Oct 11, 2008 at 1:59 PM, Michel Talon <talon at lpthe.jussieu.fr> wrote:
> 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
>>                nasm_patch=-1
>>             fi
>
> 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.

I just submitted a PR with the fix:

     http://www.freebsd.org/cgi/query-pr.cgi?pr=128042

-- 
cd /usr/ports/sysutils/life
make clean


More information about the freebsd-ports mailing list