[FFmpeg-devel] OS/2?
Måns Rullgård
mans
Wed Jul 11 01:02:06 CEST 2007
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
More information about the ffmpeg-devel
mailing list