[FFmpeg-devel] OS/2?

[Måns Rullgård]

Ramiro Ribeiro Polla <ramiro at lisha.ufsc.br> writes:

[configure]
> Left for Mans to clean up.

Done.

>> these are ok to remove, actually the __MINGW32__ is ugly too and should be
>> done differently, that is by checking for the availability of the used stuff
>> not for the OS/environment
>
> Done. I'll look into that __MINGW32__ part now.

Terrific.

>>>  // Use rip-relative addressing if compiling PIC code on x86-64.
>>>  #if defined(__MINGW32__) || defined(__CYGWIN__) || \
>>> -    defined(__OS2__) || (defined (__OpenBSD__) && !defined(__ELF__))
>>> +    (defined (__OpenBSD__) && !defined(__ELF__))
>>>  #    if defined(ARCH_X86_64) && defined(PIC)
>>>  #        define MANGLE(a) "_" #a"(%%rip)"
>>>  #    else
>>>     
>>
>> this should really be checked for in configure and not by keeping a long
>> #ifdef list
>
> Left as is.
> Isn't there a way to remove MANGLE completely? I once had a problem 
> compiling vorbis on MinGW (the encoder lacked the correct ifdef), and 
> when I asked on #vorbis at freenode.net about this issue, the guy wrote the 
> decoder went on and on about how bad MANGLE was, and that he got rid of 
> all those problems when he switched to the "m" constraint.

The mangle.h header has already been removed.  I don't know what it
would take to clean up the assembler constructs.  Using the "m"
constraint is less than ideal since it specifies a memory operand,
whereas registers are faster.

>>> Index: libavcodec/Makefile
>>> ===================================================================
>>> --- libavcodec/Makefile	(revision 9470)
>>> +++ libavcodec/Makefile	(working copy)
>>> @@ -318,7 +318,6 @@
>>>  
>>>  OBJS-$(HAVE_PTHREADS)                  += pthread.o
>>>  OBJS-$(HAVE_W32THREADS)                += w32thread.o
>>> -OBJS-$(HAVE_OS2THREADS)                += os2thread.o
>>>  OBJS-$(HAVE_BEOSTHREADS)               += beosthread.o
>>>  
>>>  OBJS-$(HAVE_XVMC_ACCEL)                += xvmcvideo.o
>>>     
>>
>> iam against removing os2thread.c
>> the file does no harm IMHO
>> removing it might cause some poor guy to waste his time reimplementing
>> it
>>
>>   
>
> Not removed. Although I vote to removing it (that is, if my vote really 
> counts on this issue).

I see no point in keeping old cruft rotting in the tree.  In other
words, I also vote for removing it.

-- 
M?ns Rullg?rd
mans at mansr.com