[Ffmpeg-devel] Re: [PATCH] MinGW and portability

[Måns Rullgård]

Frantisek Dvorak said:
>>> +#ifdef AVFORMAT_COMPILE
>>> +#  define _DL_IMPORT_AVFORMAT
>>> +#else
>>> +#  define _DL_IMPORT_AVFORMAT _DL_IMPORT
>>> +#endif
>>
>> What's this all about?  People are compiling and using ffmpeg on
>> windows all the time without any mess like this.
>>
>
> With compiling ffmpeg Windoze users are forced to use recent MinGW or

If you want to use new software you have to be prepared to use new compilers.
End of story.

> CygWin. It's probably OK, since ffmpeg contains various nifty and
> naughty things. :-> Users/developers with ancient compilers (it includes
> "ancient" MinGW with gcc 2.95!) need this.
>
>>> Index: qt-faststart.c
>>> ==================================================================>> RCS
>>> file: /cvsroot/ffmpeg/ffmpeg/qt-faststart.c,v
>>> retrieving revision 1.8
>>> diff -u -p -u -r1.8 qt-faststart.c
>>> --- qt-faststart.c	27 Mar 2006 16:34:21 -0000	1.8
>>> +++ qt-faststart.c	28 Mar 2006 18:02:39 -0000
>>> @@ -20,13 +20,24 @@
>>>   * presently only operates on uncompressed moov atoms.
>>>   */
>>>
>>> +#include "config.h"
>>>  #include <stdio.h>
>>>  #include <stdlib.h>
>>> +#ifdef HAVE_INTTYPES_H
>>>  #include <inttypes.h>
>>> +#endif
>>> +#ifdef HAVE_STDINT_H
>>> +#include <stdint.h>
>>> +#endif
>>
>> Both inttypes.h and stdint.h are standard C.  If you are missing them
>> you should fix your environment.
>>
>
> Standard C?

ISO/IEC 9899:1999 aka C99.

> I agree good environments should have it, but there already
> are some check for inttypes.h in configure to make ffmpeg as portable as
> possible.

I suppose those checks have been there since before C99 compilers and
runtimes were easily available everywhere.  I've run into similar problems
on Solaris and AIX, but at least Solaris is now up to date.

> Comments to Rich Felker:
>
>> This patch was already rejected once before. The solution is to add
>> the equivalent of -Dnear=msvc_sucks_near to your build options, not to
>> invasively alter valid C code to workaround MS bugs.
>
> Cute trick. I'll use it thanks. (btw. not only M$VC, whole WIN32 sucks
> near :-), maybe should be used in ffmpeg configure too...)

I always thought "near" and "far" pointers were a thing of 16-bit segmented
memory models.  Win32 is supposed to use a linear memory model, no?

-- 
M?ns Rullg?rd
mru at inprovide.com