Error cross compiling for windows

[1MarcosDev]

Hello, first I wanted to congratulate and thank you for bringing raylib to our amazing nim. It really is an amazing job.

I'm having a problem compiling from linux to windows. When using the command:

nim c -d:mingw main.nim

the compiler gives me the following error:

Hint: used config file '/home/Marcos/.choosenim/toolchains/nim-1.6.8/config/nim.cfg' [Conf]
Hint: used config file '/home/Marcos/.choosenim/toolchains/nim-1.6.8/config/config.nims' [Conf]
...........................................................................................io.nim(759)              open
Error: unhandled exception: cannot open: ..\csources\raylib_mangled\rglfw.c [IOError]

Even though I already have the glfw package installed, the error persists. Any idea how I can solve this error?

Thanks in advance for the answer!

[greenfork]

Hi, thank you for your kind words!

Unfortunately cross-compilation story for Nim is not that good.

I have not tested cross-compilation to Windows from Linux and from what I've heard it is better to do it via a docker container. Nim story for cross-compilation is not the greatest. Right here the problem is:

• I use / function from os module which translates path separators to / on Linux and to \ for Windows
• MinGW inserts headers telling that this is a Windows build
• Path separators are translated to \
• Linux system doesn't understand this path separator

Generally the problem is that Nim doesn't have different concepts for host OS and target OS. So there are some quirks. If you want to cross-compile - the best option is to find someone doing it via "GitHub actions" and take their build script. It should compile the Nim program on Windows and upload it to "Releases" section. It could be possible to do this locally too but I've never done it so can't comment.

If you happen to find a reliable way to do cross-compilation, you are welcome to post it here or make a pull request, maybe adding a GitHub action file to the contrib/ directory or something similar.

[1MarcosDev]

Well, this is relatively interesting. Now that I know where the root of the problem is, I can try to solve it. I'll leave this open for now, any solution I find I'll post here.

[1MarcosDev]

A very interesting update! I assumed the problem was the way nim was handling files, and reading through the library I found that the source of the error was in the static_build.nim file. For testing purposes, I copied all dependency files to the location where static_build.nim was, and oddly enough, it brought results. Doing so, nim compiles all files with the exception of rcore, returning this error:

CC: rglfw
CC: rshapes
CC: rtextures
CC: rtext
CC: utils
CC: rmodels
CC: raudio
CC: rcore
/home/Marcos/.nimble/pkgs/nimraylib_now-0.15.0/nimraylib_now/rcore.c:212:14: fatal error: GLFW/glfw3.h: Arquivo ou diretório inexistente
  212 |     #include "GLFW/glfw3.h"         // GLFW3 library: Windows, OpenGL context and Input management
      |              ^~~~~~~~~~~~~~
compilation terminated.

Now the solution is simple, I just need to find a way for nim to read the path regardless of the system.

[1MarcosDev]

Well, closing this issue, I have two points:

First: Currently, the os module is no longer necessary to convert the paths from linux to windows, nim does this automatically in the cross compilation. The modifications I made to the static_build.nim file were as follows:

# Line 89
else:
  {.compile: "../csources/raylib_mangled/rglfw.c".}

{.compile: "../csources/raylib_mangled/rshapes.c".}
{.compile: "../csources/raylib_mangled/rtextures.c".}
{.compile: "../csources/raylib_mangled/rtext.c".}
{.compile: "../csources/raylib_mangled/utils.c".}
{.compile: "../csources/raylib_mangled/rmodels.c".}
{.compile: "../csources/raylib_mangled/raudio.c".}
{.compile: "../csources/raylib_mangled/rcore.c".}

This is just what is needed for nim to recognize the files regardless of the platform, as the compiler will take care of converting the paths.

Second: Even with the changes I still can't do the cross compilation, but this is no longer a library error, but the relationship with GLFW and MINGW, and as my knowledge in c and c++ is extremely limited, I will close this issue, but I hope this helps you in some way.

[greenfork]

Thank you for your research! I will try to go from there, even replacing slashes is a step forward.