Compilation issues with single file builds (Unity Builds) about glfw

[ThatOSDev]

Just to give a bit more info.

I have tried to undefine the 4 NULL functions to no avail.

I'm using GCC 13.2 ( MinGWx64 ) on windows.
FROM HERE: https://nuwen.net/mingw.html

Windows 10 Home 22H2

EDIT :
In GLFW 3.3.8 I could compile it without problems. No NULL files needed.

[dougbinks]

I compile GLFW in Windows with the files added manually to my project, including the null_ files, and do not have any compile or link errors.

Could you report the errors you are seeing when you include the null_ files?

Note that when compiling GLFW manually there are a number of compile options you need to set, these are generated in glfw_config.h by the CMake script, so if needed you could run CMake to generate it for you. For windows this is just #define _GLFW_WIN32 plus #define _GLFW_BUILD_DLL if you want to build a DLL.

[ThatOSDev]

I compile GLFW in Windows with the files added manually to my project, including the null_ files, and do not have any compile or link errors.

Could you report the errors you are seeing when you include the null_ files?

Note that when compiling GLFW manually there are a number of compile options you need to set, these are generated in glfw_config.h by the CMake script, so if needed you could run CMake to generate it for you. For windows this is just #define _GLFW_WIN32 plus #define _GLFW_BUILD_DLL if you want to build a DLL.

Yes, I am using the #define _GLFW_WIN32. I'm not making a DLL so the other define has no baring on this problem.

I did report the problem when I DO include those 4 NULL files.

Older versions 3.8.8 and 3.3.10 work fine as I posted in my original post.

So this problem is with the NULL being required... Here is the error if I do NOT add the NULL files.

glfw-3.4\src\platform.c:79 undefined reference to _glfwConnectNull

If I ADD the 4 required NULL files, then as my original post shows, I get redefine errors for those 4 functions. Only way I found around it is for me to just block them out in the null_windows.c file. I can't even undefine them.

[dougbinks]

If I ADD the 4 required NULL files, then as my original post shows, I get redefine errors for those 4 functions.

Which four functions? Could you paste the output error message text from your compile?

Re-reading your initial post I realise you are literally #include-ing the source files from GLFW. I thought this was just a way to say you were including these in your build script.

GLFW does not currently support Unity Builds, so this will fail. You should include the source files one by one in your build script/system.

There was a PR for re-naming functions so unity build would work, but for some reason the author closed it.

[ThatOSDev]

Just dawned on me that you are talking about adding files within a file, (UNITY BUILD) kind of like the library RAYLIB does. I have done the same thing with all previous versions of GLFW without problems. The latest 3.4 release version however is different.

Since you no longer are supporting that, then I will just edit the files anytime I update to get it to work.

Sorry to waste your time.

[dougbinks]

I've reopened this issue as single file (Unity Build) is something we probably should support, it's just that we do not do so explicitly at the moment (so the fact that it worked in the past was a happy accident).

Could you post the error message you get when compiling or the names of the four function names which clash? If you don't have that information to hand then do not worry as we can easily figure that out once I take a look at this issue, but it would speed things up.

[abryzak]

I ran into this same issue yesterday and a simple fix is to redefine conflicting names and include the null platform in the build. I think you would need to do a similar thing if you were compiling with both X11/Wayland for Linux. For reference this is how I build it as part of a unity build:

/***** GLFW *****/
// Enable extensions, mostly because GLFW uses ppoll
// and doesn't do this before they include poll.h
#define _GNU_SOURCE

#define _GLFW_X11
#include "dependencies/glfw-3.4/src/context.c"
#include "dependencies/glfw-3.4/src/egl_context.c"
#include "dependencies/glfw-3.4/src/glx_context.c"
#include "dependencies/glfw-3.4/src/init.c"
#include "dependencies/glfw-3.4/src/input.c"
#include "dependencies/glfw-3.4/src/linux_joystick.c"
#include "dependencies/glfw-3.4/src/monitor.c"
#include "dependencies/glfw-3.4/src/osmesa_context.c"
#include "dependencies/glfw-3.4/src/platform.c"
#include "dependencies/glfw-3.4/src/posix_module.c"
#include "dependencies/glfw-3.4/src/posix_poll.c"
#include "dependencies/glfw-3.4/src/posix_thread.c"
#include "dependencies/glfw-3.4/src/posix_time.c"
#include "dependencies/glfw-3.4/src/vulkan.c"
#include "dependencies/glfw-3.4/src/window.c"
#include "dependencies/glfw-3.4/src/wl_init.c"
#include "dependencies/glfw-3.4/src/wl_monitor.c"
#include "dependencies/glfw-3.4/src/wl_window.c"
#include "dependencies/glfw-3.4/src/x11_init.c"
#include "dependencies/glfw-3.4/src/x11_monitor.c"
#include "dependencies/glfw-3.4/src/x11_window.c"
#include "dependencies/glfw-3.4/src/xkb_unicode.c"

// we need to rename these functions as the "null" platform is
// always linked by platform.c and it defines some static
// functions that conflict with the ones in the other platforms

#define acquireMonitor acquireMonitorNull
#define releaseMonitor releaseMonitorNull
#define createNativeWindow createNativeWindowNull

#include "dependencies/glfw-3.4/src/null_init.c"
#include "dependencies/glfw-3.4/src/null_joystick.c"
#include "dependencies/glfw-3.4/src/null_monitor.c"
#include "dependencies/glfw-3.4/src/null_window.c"

#undef acquireMonitor
#undef releaseMonitor
#undef createNativeWindow

A better solution for me personally would be to give those static functions a unique name per platform and possibly make the null platform optionally included with defines like the other platforms.

[abryzak]

The only other name that I see that conflicts with null and win32 is fitToMonitor

[ThatOSDev]

Yea the 4 names that clash are :

acquireMonitor
releaseMonitor
createNativeWindow
fitToMonitor

It shows that they are redefined.

Hope this helps.

[dougbinks]

Many thanks to you both for that list of functions, that helps.