Closed GoogleCodeExporter closed 9 years ago
solution 3 : implement a MGLUTWindow...
Original comment by skaiw...@gmail.com
on 22 Aug 2012 at 9:32
corection : the MWin32Window does not need directx, just direct.h. should be
compilable on cygwin...
Original comment by skaiw...@gmail.com
on 22 Aug 2012 at 9:34
Someone compiled Maratis with Mingw :
http://forum.maratis3d.com/viewtopic.php?id=321
Normally everything should compile, the problem might be more with scons not
recognizing the platform.
What are the build errors ?
Original comment by anael.se...@gmail.com
on 23 Aug 2012 at 10:38
We might need to modify dirent.py to pass when using CYGWIN, as cygwin don't
need the win32 dirent port
Original comment by anael.se...@gmail.com
on 23 Aug 2012 at 10:57
Hi Anael,
1 - nowadays mingw and cygwin are more and more different but at first there
was the same issue in MFile.h that you did not fixed : you have to add this to
MFile.h:
#include <stdarg.h> // needed for va_list
Why did n't you fixed it ?
2 - I have fixed some scons file as described for example in joined file
libsndfile.h
3 - dirent.h seems available on cygwin so we could use it if needed.
4 - could you apply these changes before I continue or not ?
Kind,
S.
Original comment by skaiw...@gmail.com
on 23 Aug 2012 at 8:32
do you still get errors ?
can you send me a svn patch of your fix so I can apply it ?
Original comment by anael.se...@gmail.com
on 24 Aug 2012 at 7:40
added stdarg to svn
Original comment by anael.se...@gmail.com
on 28 Aug 2012 at 2:21
Hi Anael, please excuse, was on holidays.
Here is the diff.
S.
Original comment by skaiw...@gmail.com
on 28 Aug 2012 at 7:46
Attachments:
Consequently, Anael, what would you prefer in order to finish cygwin support ?
1 - implement a MGLUTWindow ?
2 - implement a MSDLWindow ?
3 - enhance MX11Window to work with or without XF86VideoMode ?
4 - fix Win32 Window to compile under cygwin : there is currently some
compilation errors when :
#ifndef (__CYGWIN__)
#include <direct.h>
#endif
Original comment by skaiw...@gmail.com
on 28 Aug 2012 at 7:54
Hi, thank you.
X11 should work, xf86VideoMode is mainly used for fullscreen mode.
Can you check if cygwin have <X11/extensions/Xrandr.h> ? If there is Xrandr, it
can replace xf86VideoMode for the fullscreen mode, if not, the fullscreen mode
can just be disabled.
Original comment by anael.se...@gmail.com
on 29 Aug 2012 at 9:09
Hi Anael
OK thanks.
You have still not patched libsndfile.py as I propose.
Waiting for this before continuing.
S.
Original comment by skaiw...@gmail.com
on 29 Aug 2012 at 5:30
Ok, I applied your patch with a little modification for MWindow, it's using X11
with XF86VideoMode disabled. It should work but without fullscreen mode, if you
can test.
If everything works, we can then use Xrandr to get the fullscreen back.
Original comment by anael.se...@gmail.com
on 29 Aug 2012 at 6:24
[deleted comment]
glGenerateMipmapEXT and all extensions are generated by glee.c
Original comment by anael.se...@gmail.com
on 30 Aug 2012 at 8:00
I looked at glee.h, I'm not sure weather for cygwin it need to use the WIN32
includes or the X includes, maybe you can try adding "|| __CYGWIN__" in glee.h :
#ifdef WIN32 || __CYGWIN__
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <GL/gl.h>
Original comment by anael.se...@gmail.com
on 30 Aug 2012 at 8:10
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
I think it's in <GL/glx.h>, at least in linux.
Should it not use the wglGetProcAddress one ? with defining a #ifdef WIN32 ||
__CYGWIN__
?
Original comment by anael.se...@gmail.com
on 30 Aug 2012 at 10:24
glXGetProcAddressARB is indeed in usr/include/GL/glx.h :
/*
* ARB 2. GLX_ARB_get_proc_address
*/
#ifndef GLX_ARB_get_proc_address
#define GLX_ARB_get_proc_address 1
typedef void (*__GLXextFuncPtr)(void);
extern __GLXextFuncPtr glXGetProcAddressARB (const GLubyte *);
#endif /* GLX_ARB_get_proc_address */
but the error is a link error, not a compile error.
Lets check win32...
Original comment by skaiw...@gmail.com
on 31 Aug 2012 at 10:55
wglGetProcAddress is indeed in lib/w32api/libopengl32.a
I have added this lib in the link process : -lopengl32
but if I modify glee.c to point to wglGetProcAddress
then several undefined reference to `_wglGetProcAddress'
Original comment by skaiw...@gmail.com
on 31 Aug 2012 at 11:08
10.4. Problems linking OpenGL applications? Undefined reference to _glsomething?
Cygwin has two OpenGL implementations:
- headers in /usr/include/openGL, libraries (-lglut32 -lglu32 -lopengl32) from
the opengl and w32api packages which are for displaying OpenGL graphics
directly through the native Windows interface (Win32) without any X server
- headers in /usr/include/GL, libraries (-lglut -lglu -lgl) from the Mesa libGL
packages (libGL-devel, libGL1, libGLU-devel, libGLU1, libglut-devel, libglut3,
freeglut) which are for displaying OpenGL graphics through an X server.
These are incompatible, even the headers (as the native OpenGL API has the
stdcall calling convention), so you must exercise care if you have both sets of
devel packages installed. An application must be built using only one of these.
- X applications using GLX must be built using option 2.
- Applications using GLUT have a choice.
- Applications using the WGL API must be built using option 1.
...
Original comment by skaiw...@gmail.com
on 31 Aug 2012 at 1:02
I found on Internet that there is an option to force the compatibility to WIN32
to compile like mingw but with cygwin :
gcc -mno-cygwin
Don't know if it can be of use
Original comment by anael.se...@gmail.com
on 31 Aug 2012 at 2:12
I have added self.CppCommonFlags = '-mno-cygwin' in compileroptions.py :
g++: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.
This is probably when using mingw compiler, not the usual cygwin g++. Swaping
ot mingw would be too much work and normal g++ should work.
Original comment by skaiw...@gmail.com
on 31 Aug 2012 at 4:28
I have created a cygwin section in compileroptions.py and here is the current
work in progress status :
1 - if defining WIN32 with
self.CppCommonDefines = 'WIN32 _MBCS'
and using MWin32Window, everything compiles fine but when linking
ManualUse.exe, there are some undefined references as _joyGetDevCaps ... even
if I add winmm and other libs... through
env.AppendUnique(LIBS = ['winmm', 'User32', 'Shell32', 'Gdi32', 'Comdlg32',
'glaux'])
2 - if not defining WIN32, swaping to MX11Window, everything compile fine but
ManualUse.exe failed to link with : undefined reference to `_glXGetProcAddress'
or undefined reference to `_glXGetProcAddressARB'
The changes does not touch any existing supported platforms. Could I/you commit
?
Original comment by skaiw...@gmail.com
on 31 Aug 2012 at 4:43
I think the good way should be WIN32.
I found some code on GLFW with a makefile for cygwin :
http://www.koders.com/noncode/fid8456C569443C61785EFB44846BA7777B191D8D98.aspx?s
=%22mercy%22
I've seen they use this additional include for cygwin (should be added to the
WIN32 MWindow) :
#if defined(__MINGW32__) || defined(__CYGWIN__)
#include <w32api.h>
Original comment by anael.se...@gmail.com
on 31 Aug 2012 at 5:16
I commit the w32api.h modification and port the dependency to direct.h
Original comment by anael.se...@gmail.com
on 2 Sep 2012 at 9:49
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
Hi,
nice work, thanks !
William, I added you to the project, you can normally commit to svn.
Original comment by anael.se...@gmail.com
on 3 Sep 2012 at 8:28
[deleted comment]
here it is, that works : to be carefull, to resume :
- the order of libs is important : for example glee must be before opengl32
- the GL headers are important : for WIN32 compilation, do not use the
/usr/include/GL but /usr/include/w32api/GL ones
Original comment by skaiw...@gmail.com
on 4 Sep 2012 at 7:50
Attachments:
Perfect, so I'm closing this,
good work, thanks !
Original comment by anael.se...@gmail.com
on 6 Sep 2012 at 3:44
Original issue reported on code.google.com by
skaiw...@gmail.com
on 21 Aug 2012 at 10:08Attachments: