[build] raylib doesn't build under mingw-w64 #243

Phyllostachys · 2017-03-09T01:58:44Z

I tried building raylib 1.6 in MinGW-w64 but there are name conflicts with the wingdi system that MinGW-w64 exposes. I tried taking that include path out but GL/gl.h, as required by GLFW3, is in the w32api folder path which includes the wingdi.h files.

The log looks like this:

$ make
gcc -c core.c -O1 -Wall -std=gnu99 -fgnu89-inline -Wno-missing-braces -I. -Iexternal -Iexternal/glfw3/include -Iexternal/openal_soft/include -DPLATFORM_DESKTOP -DBUILDING_STATIC
In file included from /usr/include/w32api/windows.h:71:0,
                 from /usr/include/w32api/GL/gl.h:13,
                 from external/glfw3/include/GLFW/glfw3.h:168,
                 from core.c:71:
/usr/include/w32api/wingdi.h:3049:28: error: ‘Rectangle’ redeclared as different kind of symbol
   WINGDIAPI WINBOOL WINAPI Rectangle(HDC hdc,int left,int top,int right,int bottom);
                            ^~~~~~~~~
In file included from core.c:45:0:
raylib.h:345:3: note: previous declaration of ‘Rectangle’ was here
 } Rectangle;
   ^~~~~~~~~
In file included from /usr/include/w32api/windows.h:72:0,
                 from /usr/include/w32api/GL/gl.h:13,
                 from external/glfw3/include/GLFW/glfw3.h:168,
                 from core.c:71:
/usr/include/w32api/winuser.h:2210:29: error: conflicting types for ‘CloseWindow’
   WINUSERAPI WINBOOL WINAPI CloseWindow (HWND hWnd);
                             ^~~~~~~~~~~
In file included from core.c:45:0:
raylib.h:623:12: note: previous declaration of ‘CloseWindow’ was here
 RLAPI void CloseWindow(void);                                     // Close Window and Terminate Context
            ^~~~~~~~~~~
In file included from /usr/include/w32api/windows.h:72:0,
                 from /usr/include/w32api/GL/gl.h:13,
                 from external/glfw3/include/GLFW/glfw3.h:168,
                 from core.c:71:
/usr/include/w32api/winuser.h:3609:25: error: conflicting types for ‘ShowCursor’
   WINUSERAPI int WINAPI ShowCursor(WINBOOL bShow);
                         ^~~~~~~~~~
In file included from core.c:45:0:
raylib.h:631:12: note: previous declaration of ‘ShowCursor’ was here
 RLAPI void ShowCursor(void);                                      // Shows cursor
            ^~~~~~~~~~
core.c:263:13: error: conflicting types for ‘SwapBuffers’
 static void SwapBuffers(void);                          // Copy back buffer to front buffers
             ^~~~~~~~~~~
In file included from /usr/include/w32api/windows.h:71:0,
                 from /usr/include/w32api/GL/gl.h:13,
                 from external/glfw3/include/GLFW/glfw3.h:168,
                 from core.c:71:
/usr/include/w32api/wingdi.h:4186:28: note: previous declaration of ‘SwapBuffers’ was here
   WINGDIAPI WINBOOL WINAPI SwapBuffers(HDC);
                            ^~~~~~~~~~~

It also doesn't seem to like the names near and far:

core.c: In function ‘GetMouseRay’:
core.c:1050:20: error: expected identifier or ‘(’ before ‘=’ token
     Quaternion far = { deviceCoords.x, deviceCoords.y, 1.0f, 1.0f };
                    ^
core.c:1054:29: error: expected expression before ‘,’ token
     QuaternionTransform(&far, matProjView);
                             ^
core.c:1058:31: error: expected ‘=’ before ‘/’ token
     Vector3 farPoint = { far.x/far.w, far.y/far.w, far.z/far.w};
                               ^
core.c:1058:42: error: expected ‘}’ before ‘.’ token
     Vector3 farPoint = { far.x/far.w, far.y/far.w, far.z/far.w};
                                          ^
core.c:1062:50: error: ‘nearPoint’ undeclared (first use in this function)
     Vector3 direction = VectorSubtract(farPoint, nearPoint);
                                                  ^~~~~~~~~

:-( I can't really think of a way around it.

The text was updated successfully, but these errors were encountered:

raysan5 · 2017-03-09T08:58:20Z

Ouch... the infamous windows.h strikes again...

I've seen this issue about conflicting types several times... GL/gl.h header shouldn't include windows.h. Checking the related lines in mingw-w64/mingw-w64-headers/include/GL/gl.h:

#if !(defined(WINGDIAPI) && defined(APIENTRY))
#include <windows.h>
#else
#include <stddef.h>
#endif

You can try defining WINGDIAPI at compilation... let me know if it works...

About near and far issue, I'll change those names ASAP.

raysan5 · 2017-03-09T10:14:58Z

I compared GL\gl.h from mingw32 and mingw-w64. Personally, I find better organized and with more comments the mingw32 implementation (and it doesn't require windows.h).

Just for reference, here it is the header definitions system on mingw32 GL\gl.h:

/************************************************************************
 * Begin system-specific stuff.
 */
/* __WIN32__ */
#if !defined(__WIN32__) && (defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__))
#  define __WIN32__
#endif

/* GLAPI, part 1 (use WINGDIAPI, if defined) */
#if defined(__WIN32__) && defined(WINGDIAPI)
#  define GLAPI WINGDIAPI
#endif

/* GLAPI, part 2 */
#if !defined(GLAPI)
#  if defined(_MSC_VER)                        /* Microsoft Visual C++ */
#    define GLAPI __declspec(dllimport)
#  elif defined(__LCC__) && defined(__WIN32__) /* LCC-Win32 */
#    define GLAPI __stdcall
#  else                                        /* Others (e.g. MinGW, Cygwin, non-win32) */
#    define GLAPI extern
#  endif
#endif

/* APIENTRY */
#if !defined(APIENTRY)
#  if defined(__WIN32__)
#    define APIENTRY __stdcall
#  else
#    define APIENTRY
#  endif
#endif
/*
 * End system-specific stuff.
 ************************************************************************/

in comparison to the mingw-w64 GL\gl.h:

#if !(defined(WINGDIAPI) && defined(APIENTRY))
#include <windows.h>
#else
#include <stddef.h>
#endif

Note that gl.h functions definition in mingw32 follow the declaration style:

GLAPI void APIENTRY glVertex3f( GLfloat x, GLfloat y, GLfloat z );

while the gl.h funtions definition in mingw-w64are:

WINGDIAPI void APIENTRY glVertex3f( GLfloat x, GLfloat y, GLfloat z );

raysan5 · 2017-03-09T10:37:15Z

Ok, as I see it, windows.h is ONLY required to define WINGDIAPI in case it is not defined... seems a bit cumbersome...

Actually, WINGDIAPI is not defined in windows.h, it's defined in wingdi.h:

#ifdef _GDI32_
#define WINGDIAPI
#else
#define WINGDIAPI DECLSPEC_IMPORT
#endif

And DECLSPEC_IMPORT is defined who knows where (multiple source files), sometimes with value __declspec(dllimport) and sometimes blank...

When I see all this, I keep asking myself: really? it needs to be that way? needs to be so complex? Just created raylib to make things easier and simpler... programming shouldn't be that convoluted...

Phyllostachys · 2017-03-09T12:46:09Z

When I see all this, I keep asking myself: really? it needs to be that way? needs to be so complex? Just created raylib to make things easier and simpler... programming shouldn't be that convoluted...

I hear you there on that one! Nobody likes KISS anymore.

I'll try tinkering with it more. Any idea why it doesn't like near/far? I've never encountered that before and they aren't reserved words.

Phyllostachys · 2017-03-09T13:00:40Z

Oh... This is interesting. I'm on another machine with MinGW-w64 installed and it built fine. I think I do have some extra mingw headers installed on the other machine... I suspect that it picked up some headers that nobody anticipated it picking up.

Here are build outputs without and with -v passed to gcc.

raysan5 · 2017-03-09T15:27:44Z

Hi @Phyllostachys! Thanks for the info!

It seems in one machine there are some headers around that complicate things... do you have Visual Studio installed in any of the two machines? Which version? Maybe it creates some environment definitions...

About far and near, they seem to be no-standard reserved words to deal with 16 bit and 32 bit pointers, that's the reason the compiler complaints. More info here:

http://stackoverflow.com/questions/1749904/what-is-the-difference-between-far-pointers-and-near-pointers
http://www.cplusplus.com/forum/general/12435/

Just renamed in commit 4ec65c0

Glad to read it compiles now.

I recommend you to use raylib develop branch, it contains latest updates and I try to keep the branch stable. Hopefully raylib 1.7 will be published anythime soon. :)

Phyllostachys · 2017-03-09T17:34:06Z

I have MSVC command line build tools install on both. I'll have to see what is installed in MinGW on the other machine to see what is extra. I'll try the develop branch too. Thanks a bunch!

raysan5 · 2017-03-09T17:55:00Z

Thanks to you for trying the library and reporting the issue! :)

Phyllostachys closed this as completed Mar 9, 2017

jgabaut mentioned this issue Jun 6, 2024

[rlgl] Rename near, far variables #4039

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[build] raylib doesn't build under mingw-w64 #243

[build] raylib doesn't build under mingw-w64 #243

Phyllostachys commented Mar 9, 2017

raysan5 commented Mar 9, 2017

raysan5 commented Mar 9, 2017 •

edited

Loading

raysan5 commented Mar 9, 2017 •

edited

Loading

Phyllostachys commented Mar 9, 2017

Phyllostachys commented Mar 9, 2017

raysan5 commented Mar 9, 2017

Phyllostachys commented Mar 9, 2017

raysan5 commented Mar 9, 2017

[build] raylib doesn't build under mingw-w64 #243

[build] raylib doesn't build under mingw-w64 #243

Comments

Phyllostachys commented Mar 9, 2017

raysan5 commented Mar 9, 2017

raysan5 commented Mar 9, 2017 • edited Loading

raysan5 commented Mar 9, 2017 • edited Loading

Phyllostachys commented Mar 9, 2017

Phyllostachys commented Mar 9, 2017

raysan5 commented Mar 9, 2017

Phyllostachys commented Mar 9, 2017

raysan5 commented Mar 9, 2017

raysan5 commented Mar 9, 2017 •

edited

Loading

raysan5 commented Mar 9, 2017 •

edited

Loading