Sean McGovern <[email protected]> writes:
> On 7/25/11, Måns Rullgård <[email protected]> wrote:
>> Sean McGovern <[email protected]> writes:
>>
>>> Sun's compiler does not like much of the libav inline assembly, so disable
>>> it by default.
>>> ---
>>> configure | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index a83d339..2b41a4c 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2016,6 +2016,7 @@ elif $cc -V 2>&1 | grep -q Sun; then
>>> DEPEND_CMD='$(DEPCC) $(DEPFLAGS) $< | sed -e "1s,^.*: ,$@: ," -e
>>> "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
>>> DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -xM1'
>>> add_ldflags -xc99
>>> + disable asm
>>> speed_cflags='-O5'
>>> size_cflags='-O5 -xspace'
>>> filter_cflags=suncc_flags
>>> --
>>
>> This disables *all* asm, even yasm, which is probably not what you want.
>> The proper solution is to put all inline asm under #if HAVE_INLINE_ASM
>> as is done for most other architectures.
>>
>> --
>> Måns Rullgård
>> [email protected]
>
>>
>
> OK, discard this patch then. I will see what I can do about individual
> problems.
>
> I started by investigating libavutil/x86/cpu.c last night.. It's
> causing an ICE on line 77 -- a call to the cpuid() macro. I'm not at
> the machine right now so I can't provide the error message. Oddly
> enough if I disable optimization or just comment out that line, it
> compiles fine -- the other calls to cpuid() don't have an issue.
Gah, I forgot inline asm is used for cpuid, which in turn is required to
enable any of the other asm functions.
> I _think_ Sun CC is barfing on the union defined on line 48:
>
> union { int i[3]; char c[12]; } version;
>
> ...especially because if I replace each of the union elements with
> separate ints, it again compiles, with obviously incorrect results as
> the union is now only zeroes.
Does it give correct results if you store those values into the union
after the cpuid() call?
> Any thoughts or words of encouragement?
Compilers suck.
--
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
