troubles compiling on cygwin, portability issues
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. 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. 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. 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... Oh, and sorry for mixing user/dev stuff in this message; it's sorta hard to divide it up well. Rich
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/ - ____________________________________________
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@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
Did you try to add an empty main() function or -lm at the end of gcc line ? (from cygwin faq entry about this issue)
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@16 unresolved) so I just disabled that stuff -- maybe this was bad. :)
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
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@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/ - ____________________________________________
On Wed, Jul 31, 2002 at 10:38:06AM +0200, Felix Buenemann wrote:
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...
I thought the older cygwins didn't have the definitions at all -- thats why mplayer provides its own inttypes.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@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
Shouldn't this hack be removed now since it just duplicates -vop expand in a broken way?
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", ...).
It was added quite a long time ago -- I imagine there have been (at least minor) changes to the vo architecture since then that would break the old vo_sdl.c. Unfortunately I no longer have access to the box I was testing on, but I can probably test on another box instead sometime. Rich
On Wednesday 31 July 2002 18:09, D Richard Felker III wrote:
On Wed, Jul 31, 2002 at 10:38:06AM +0200, Felix Buenemann wrote:
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...
I thought the older cygwins didn't have the definitions at all -- thats why mplayer provides its own inttypes.h. yes, so if you remove 'em from cygwin_inttypes.h old cygwins won't build anymore, probably try to find out if cygwin defines it's version in some macro, it could be used to only have these defs if needed.
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@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
Shouldn't this hack be removed now since it just duplicates -vop expand in a broken way? probably yes, but I'm not sure yet -vop expand is as efficient, needs some sorrow testing, also it would be nice if the expand could be autoloaded intead of always needing to figure out the right params.
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", ...).
It was added quite a long time ago -- I imagine there have been (at least minor) changes to the vo architecture since then that would break the old vo_sdl.c. jein, you'll probably only loose direct rendering capability (which isn't fully impelemented it seems anyways, at least dr1 doesn't work, as most of that code was added by Fredrik not by me, I can't say much about it).
Unfortunately I no longer have access to the box I was testing on, but I can probably test on another box instead sometime. ok. watching Memento now, erm I mean I'm going to test mplayer's rendering capabilities ;)
Rich
-- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________
On Wed, Jul 31, 2002 at 11:32:36PM +0200, Felix Buenemann wrote:
On Wednesday 31 July 2002 18:09, D Richard Felker III wrote:
On Wed, Jul 31, 2002 at 10:38:06AM +0200, Felix Buenemann wrote:
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...
I thought the older cygwins didn't have the definitions at all -- thats why mplayer provides its own inttypes.h. yes, so if you remove 'em from cygwin_inttypes.h old cygwins won't build anymore, probably try to find out if cygwin defines it's version in some macro, it could be used to only have these defs if needed.
Arrg, my bad. I used etc/inttypes.h instead of etc/cygwin_inttypes.h. 1l for me or something, bleh. :( Rich
On Thursday 01 August 2002 00:17, D Richard Felker III wrote:
On Wed, Jul 31, 2002 at 11:32:36PM +0200, Felix Buenemann wrote:
On Wednesday 31 July 2002 18:09, D Richard Felker III wrote:
On Wed, Jul 31, 2002 at 10:38:06AM +0200, Felix Buenemann wrote:
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...
I thought the older cygwins didn't have the definitions at all -- thats why mplayer provides its own inttypes.h.
yes, so if you remove 'em from cygwin_inttypes.h old cygwins won't build anymore, probably try to find out if cygwin defines it's version in some macro, it could be used to only have these defs if needed.
Arrg, my bad. I used etc/inttypes.h instead of etc/cygwin_inttypes.h. 1l for me or something, bleh. :( 10l at least :-P
Rich
-- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________
On Wed, Jul 31, 2002 at 11:32:36PM +0200, Felix Buenemann wrote:
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", ...).
It was added quite a long time ago -- I imagine there have been (at least minor) changes to the vo architecture since then that would break the old vo_sdl.c. jein, you'll probably only loose direct rendering capability (which isn't fully impelemented it seems anyways, at least dr1 doesn't work, as most of that code was added by Fredrik not by me, I can't say much about it).
I looked it up, and outside-movie subs were added back in revision 1.43 of vo_sdl.c. It's at 1.87 now, and there seem to be lots of major changes in architecture in between. :( Rich
participants (3)
-
D Richard Felker III -
Felix Buenemann -
Sylvain Petreolle