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

Felix Buenemann atmosfear at users.sourceforge.net
Wed Jul 31 10:38:06 CEST 2002


On Wednesday 31 July 2002 07:26, D Richard Felker III wrote:
> 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?
no, just would break build with older cygwins, hmm...


>
> > 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.
yes, surface locking seems needed on win also you should try to use an older 
vo_sdl.c. before Fredrik Kuivinen added the osd-outise-movie stuff, as 
directx doesn't like to create more than one hw surface it seems.
I think I can send you such version if you're too lazy to search cvslog, note 
that you would need to readd "directx" to the list of windowed capable 
drivers (as now "x11", "aa", ...).

> Rich
>

-- 
Best Regards,
        Atmos
____________________________________________
- MPlayer Developer - http://mplayerhq.hu/ -
____________________________________________



More information about the MPlayer-dev-eng mailing list