[MPlayer-dev-eng] troubles compiling on cygwin, portability issues

[D Richard Felker III]

On Wed, Jul 31, 2002 at 01:53:14AM +0200, Felix Buenemann wrote:
> On Tuesday 30 July 2002 20:09, D Richard Felker III wrote:
> > I've been trying to compile mplayer on cygwin, and the process hasn't
> > gone at all smoothly. First of all, mplayer's inttypes.h defines:
> >
> > typedef signed char int8_t;
> > typedef signed short int16_t;
> > typedef signed long int32_t;
> > typedef signed long long int64_t;
> >
> > All of these should be good, but the stupid cygwin sys/types.h goes
> > and defines the following conflicting types:
> >
> > typedef char int8_t;
> > typedef short int16_t;
> > typedef int int32_t;
> > typedef long long int64_t;
> >
> > Bleh. Perhaps I managed to get an old version of cygwin on the
> > computer I'm testing on (I'm not familiar with cygwin at all; I just
> > used the setup program on the website to install it), so let me know
> > if it's just something dumb on my end.
> hmm, strange I should check, I haven't had this problem yet, they probably 
> added those defs in a very recent version.

Would it be a problem to change ./etc/inttypes.h to match the (new?)
cygwin definitions?

> > A few other problems arose while I was experimenting with stuff. Now,
> > it turns out my broken SDL was trying to force the build into mingw
> > mode (eew), but I think these issues should still be fixed, since they
> > might cause portability problems on other systems:
> >
> > 1) ao_mpegpes.c tries to include sys/ioctl.h, which doesn't exist.
> >    IMHO this should only be included when DVB is enabled; it's not
> >    needed for output to file.
> yea try to put it into #ifdev HAVE_DXR3 or whatever is the name of the proper 
> macro.
> 
> > 2) spudec.[ch] use u_int and u_char typedefs. This is total nonsense
> >    -- it's just shorthand for "unsigned int" and "unsigned char" --
> >    and so it should be fixed IMO.
> yes, and I think this was discussed before, agree. simply replace with 
> unsigned <type>.

Done.

> SDL + cygwin is a major pain, you need to hack the config.mak in order to 
> remove some flags that are spit out by sdl-config, they should look like:
> SDL_LIB = -L/usr/lib -lSDLmain -lSDL -mcygwin
> SDL_INC = -I/usr/include/SDL -Dmain=SDL_main -DWIN32 -Uunix
> 
> And with some luck you know get a somewhat working -vo sdl, which is still 
> very unstable from my experiences (it seems to also have probs with the 
> multiple surfaces used, to display osd poutside picture by sdl). And you 
> probably want to build SDL with directx 5 headers+libs installed in cygwin to 
> get the directx video acceleration (I usually build with dx7 or dx8 
> libs+headers, but it requires some patching of SDL sources (maybe they always 
> need: "directx.h" -> <directx.h>).

I finally got it to work, with overlays, but it segfaults when
resizing or going fullscreen (even with -fs on the commandline). Is
this normal? I couldn't get it working with the SDLmain junk
(WinMain at 16 unresolved) so I just disabled that stuff -- maybe this
was bad. :)

Also I had to edit vo_sdl.c to turn on surface locking to keep it from
crashing altogether. This should probably be enabled by default...
Or...I was on #sdl earlier and seemed to overhear someone talking
about an undocumented function/macro to check whether a given surface
needs locking, so perhaps this would be a useful check.

Rich