Newer versions of Cygwin no longer set the _WIN32 #define. This is causing some problems that we worked around locally in MPlayer. I have replaced it with WIN32, which is used in other places in libdvdread, but possibly using __MINGW32__ and __CYGWIN__ is even better and makes the intent clearer. I'd appreciate if somebody could test this since I have no Windows system. I think libdvdread is supposed to build on Visual Studio as well, so testing that would be a bonus. Diego
Hello, On Tue, Dec 28, 2010 at 11:19:38AM +0100, Diego Biurrun wrote :
Newer versions of Cygwin no longer set the _WIN32 #define. This is causing some problems that we worked around locally in MPlayer. I have replaced it with WIN32, which is used in other places in libdvdread, but possibly using __MINGW32__ and __CYGWIN__ is even better and makes the intent clearer.
I'd appreciate if somebody could test this since I have no Windows system. I think libdvdread is supposed to build on Visual Studio as well, so testing that would be a bonus.
This will work on Win32. However, the correct C99 define for win32 defined by the compiler is _WIN32, not WIN32. I have no idea why Cygwin is doing it that way... What version of gcc is this? Best Regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ +33 672 704 734
On Tue, Dec 28, 2010 at 2:46 AM, Jean-Baptiste Kempf <jb@videolan.org> wrote:
Hello,
On Tue, Dec 28, 2010 at 11:19:38AM +0100, Diego Biurrun wrote :
Newer versions of Cygwin no longer set the _WIN32 #define. This is causing some problems that we worked around locally in MPlayer. I have replaced it with WIN32, which is used in other places in libdvdread, but possibly using __MINGW32__ and __CYGWIN__ is even better and makes the intent clearer.
I'd appreciate if somebody could test this since I have no Windows system. I think libdvdread is supposed to build on Visual Studio as well, so testing that would be a bonus.
This will work on Win32.
However, the correct C99 define for win32 defined by the compiler is _WIN32, not WIN32.
I have no idea why Cygwin is doing it that way... What version of gcc is this?
If JP is right, I don't see much chance of inclusion of this patch. Diego's suggestion to use __MINGW32__ and __CYGWIN__ has much greater chance of working out (but would probably need more testing). E -- Erik Hovland erik@hovland.org http://hovland.org/
On Sun, Jan 30, 2011 at 03:54:52PM -0800, Erik Hovland wrote :
Diego's suggestion to use __MINGW32__ and __CYGWIN__ has much greater chance of working out (but would probably need more testing).
No, I believe a better solution would be to force -D_WIN32 for CYGWIN in configure. Best Regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ +33 672 704 734
participants (3)
-
Diego Biurrun -
Erik Hovland -
Jean-Baptiste Kempf