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

[Felix Buenemann]

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.

> 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>.

> If no one objects I can commit cleanups for both these issues. Again,
> they should not be problems with cygwin in true cygwin mode (and I
> confirmed that they're not), but they could potentially cause trouble
> porting to other systems in the future.
>
> Now on to more problems. I can't seem to find any information on how
> to build a working cygwin copy of SDL. The broken SDL configure script
> builds the whole thing in mingw mode, which seems not to work with
> cygwin. Now, I know there's been success using mplayer on windows, so
> apparently someone knows how to get a working copy of SDL. Since this
> seems to be a nontrivial task it should probably be documented in the
> DOCS somewhere...
arghgrmbl&)//%$$/%

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>).

> Oh, and sorry for mixing user/dev stuff in this message; it's sorta
> hard to divide it up well.
it's ok, btw. if you want something more cruel try building gcc 3.1.1 
crosscompiler for target BeOS, you'll have something to do for days and I 
doubt you'll ever succeed ;)

> Rich
>

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