Hi, On Sun, Aug 5, 2012 at 2:20 PM, Diego Biurrun <[email protected]> wrote: > On Sun, Aug 05, 2012 at 09:35:27PM +0100, Måns Rullgård wrote: >> Diego Biurrun <[email protected]> writes: >> > On Tue, May 22, 2012 at 09:09:39PM +0200, Diego Biurrun wrote: >> >> On Sun, May 20, 2012 at 06:18:10PM +0200, Diego Biurrun wrote: >> >> > On Sat, May 19, 2012 at 04:54:18PM +0100, Måns Rullgård wrote: >> >> > > Diego Biurrun <[email protected]> writes: >> >> > > > On Sat, May 19, 2012 at 04:21:01PM +0100, Måns Rullgård wrote: >> >> > > >> Diego Biurrun <[email protected]> writes: >> >> > > >> > This avoids nasm 2.08 being detected as a compatible Assembler. >> >> > > >> > --- >> >> > > >> > Probably at least the log message needs finetuning. That said, >> >> > > >> > this works >> >> > > >> > for me and avoids nasm being detected as a working Assembler and >> >> > > >> > later >> >> > > >> > failing with >> >> > > >> > --- a/configure >> >> > > >> > +++ b/configure >> >> > > >> > @@ -2815,7 +2815,7 @@ EOF >> >> > > >> > elf*) enabled debug && append YASMFLAGS $yasm_debug >> >> > > >> > ;; >> >> > > >> > esac >> >> > > >> > >> >> > > >> > - check_yasm "pextrd [eax], xmm0, 1" && enable yasm || >> >> > > >> > + check_yasm "CPU amdnop" && enable yasm || >> >> > > >> > die "yasm not found, use --disable-yasm for a >> >> > > >> > crippled build" >> >> > > >> > check_yasm "vextractf128 xmm0, ymm0, 0" || disable avx >> >> > > >> >> >> > > >> Is that directive the only one causing trouble? >> >> > > > >> >> > > > No, there are a few others, like certain AVX instructions, that also >> >> > > > cause trouble, >> >> > > >> >> > > Aren't those disabled by the next test? >> >> > >> >> > Quite possibly that is the intention, but if I read our asm files >> >> > correctly, then not all appearances of AVX instructions are "ifdeffed". >> >> > Given my lack of familiarity with yasm syntax, I might well be wrong. >> >> >> >> Justin's patch that I just pushed fixes that issue, but the following >> >> remains: >> >> >> >> libavcodec/x86/h264_idct.asm:613: error: (call_internal:3) `%ifdef' >> >> expects macro identifiers >> >> >> >> A few dozen identical ones with different line numbers follow. >> >> Can somebody shine a light on this one? >> >> >> >> The original error message that my patch addresses is >> >> >> >> x86inc.asm:100: error: unknown 'cpu' type >> > >> > .. ping .. >> > >> > The problem persists and none of the people able to fix this have shown >> > interest in fixing nasm support. >> > >> > My patch is enough to detect failing nasm versions in practice, so I'd >> > like to push it. configure should error out when we know that compilation >> > will fail. >> >> Is this the only thing it fails on? > > No, there is another issue that i cannot quite put my finger on, which > causes errors of the type: > > error: (call_internal:3) `%ifdef' expects macro identifiers
I'm guessing this is because of the macro abstraction around "call". The purpose of these abstractions is so we can call something for cpuflags-enabled macro-functions, and call a cpuflag-specific implementation for each, e.g. something_mmx for the mmx function, but something_sse for the sse function. Nasm appears to bail if the macro is not actually defined (in which case with yasm, it defaults back to calling "just" something without a suffix). Look for all uses of call and it should be easy to comment 1-2 out and see when it disappears. Explicitely stating that the call is non-cpu'y may be a workaround. Maybe Loren has better ideas. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
