Building conflicts with windows.h for some users

[greenfork]

This is only relevant for SOME Nim installations, so far no clue why.

https://github.com/raysan5/raylib/issues/1217

For some reason in some cases Nim installation on Windows tries to compile windows.h file together with the rest of the program which causes name clashes in type definitions such as Rectangle and others. In the raylib thread there are several solutions. Another solution would be to ask Nim to NOT include windows.h file during build.

Someone needs to do that thing for me, so far I don't have a windows machine.

[HugoP707]

ill try to use nimraylib_now every once in a while to see if i can understand the issue

[greenfork]

Alright, thanks! Let me know if you have some ideas or anything, we can brainstorm it together

[Intasx]

I just had this problem. Here's what I did:

# Creating an empty sequence like this gives a compilation error:
var mySeq = newSeq[Vector2]()

compilation terminated due to -fmax-errors=3. Error: execution of an external compiler program 'gcc.exe -c -w -fmax-errors=3 -mno-ms-bitfields -DWIN32_LEAN_AND_MEAN -I\.choosenim\toolchains\nim-1.4.2\lib -I\test -o \nimcache\test_d\stdlib_system.nim.c.o \nimcache\test_d\stdlib_system.nim.c' failed with exit code: 1 (I removed the full path of the files.)

Same thing happens with Rectangle, Vector3, Quaternion, Matrix and Color, but works with any of the nim variable types: int, float...

stdlib_system.nim.c is the file that includes windows.h, so it complains about duplicate declarations of Rectangle, CloseWindow and ShowCursor.

When I create the sequence like this, it works:

var mySeq: seq[Vector2]
mySeq.add((10.0, 10.0)) # It works up to here, but...
# When trying to stringify the sequence with $ gives the same error as before
let a = $mySeq
# and because of this, I can't print the whole sequence...
echo mySeq # Or any other function that stringifies the sequence...
# This also happens with arrays

As a workaround, I just loop through the sequence and print every individual vector.

There may be other problems involving this "special" sequence and nim standard functions, but I haven't run into them yet. I'll post again if I found some other error.

[greenfork]

@Intasx thanks for investigating! I think I will try to make some attempts to mitigate this error on different branches, maybe something's going to work. So far I have no ideas but just to follow ideas in https://github.com/raysan5/raylib/issues/1217

[XDEmer0r-L0rd-360-G0d-SlayerXD]

This problem is causing me a lot of pain, hope you can figure out a solution soon. I wanted to provide my example to hope it gives you more insight into this problem.

var col = Red
if col == Red:
    echo 1

Gives the Rectangle, ect. crash. I don't understand C well enough to be able to try to fixes mentioned in your last response so there is little I can do but wait. Iirc nested procs also caused the error.

[Intasx]

I could be completely wrong since I'm no nim expert, but I think there isn't a way to "tell" it not to use windows.h (or at least not a simple way) unless you don't use certain features provided by the system module.

What I did to solve this is simply rename all the conflicting functions. For example, this file %userprofile%/.choosenim/toolchains/mingw64/x86_64-w64-mingw32/include/wingdi.h, at line 3049, has this:

WINGDIAPI WINBOOL WINAPI Rectangle(HDC hdc,int left,int top,int right,int bottom);

I renamed it to _Rectangle, and did the same with all the other functions. Luckly for me, everything is working fine.

And the great thing is you don't really have to know about C to do these changes, and the compiler is very good at pointing the conflicting functions.

It's a quick workaround and may not work for everyone, but at least now I don't have to worry about those errors anymore... for now. I'll update if something breaks again.

[greenfork]

@RecruitMain707 @Intasx @XDEmer0r-L0rd-360-G0d-SlayerXD hi! I tried to fix the windows.h conflict with this branch: windows-h-fix. Could you please try it out?

Your general approach should be something like this, in command line:

$ nimble uninstall nimraylib_now
$ nimble develop nimraylib_now # wait 6-10 mins to download, sorry :)
$ cd nimraylib_now
$ git checkout windows-h-fix

This copies master branch of this repo and sets your local installation of nimraylib_now to the correct branch. Now you could try to run any program that failed for you previously.

The branch PR is here: https://github.com/greenfork/nimraylib_now/pull/9

[Intasx]

Hey! Sorry for the late reply.

Sadly it still doesn't work, I got the same errors :(

I think this is the problem: This is in stdlib_system.nim.c, a C file that nim generates and compiles when you use certain standard functions/features:

/* Generated by Nim Compiler v1.4.2 */
/*   (c) 2020 Andreas Rumpf */
/* The generated code is subject to the original license. */
/* Compiled for: Windows, amd64, gcc */
/* Command for C compiler:
   gcc.exe -c  -w -fmax-errors=3 -mno-ms-bitfields -DWIN32_LEAN_AND_MEAN   -IC:\Users\username\.choosenim\toolchains\nim-1.4.2\lib -IC:\Users\username\nim -o C:\Users\username\nimcache\testing_d\stdlib_system.nim.c.o C:\Users\username\nimcache\testing_d\stdlib_system.nim.c */
#define NIM_INTBITS 64

/* section: NIM_merge_HEADERS */

#include "nimbase.h"
#include <string.h>
#include <setjmp.h>
#include <windows.h> // Here's the problem, windows.h is always included here!
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
// So adding the fix here won't matter because windows.h was already included
#include "C:\Users\username\nimraylib_now\src\nimraylib_now\raylib.h"

[greenfork]

Discussion on Nim forum: https://forum.nim-lang.org/t/7950

[shirleyquirk]

upstream is familiar with this issue, as you'd imagine: https://github.com/raysan5/raylib/issues/857

you could just edit the raylib header, no? as done here: https://github.com/osom8979/tbag/blob/v1.0.0/dep/raylib/migration.sh

[greenfork]

@shirleyquirk thanks for suggestions!

upstream is familiar with this issue, as you'd imagine: raysan5/raylib#857

Yes, I also linked another similar issue in the very first post. This would work if I can tell Nim to arrange the order of imports differently, i.e. include windows.h only after raylib.h.

you could just edit the raylib header, no? as done here: https://github.com/osom8979/tbag/blob/v1.0.0/dep/raylib/migration.sh

Does that also mean that I will have to compile raylib library myself? Since I will also need to rename these variables in the C files as I imagine.

[greenfork]

@RecruitMain707 @Intasx @XDEmer0r-L0rd-360-G0d-SlayerXD hi, there's a new release that should fix this problem. Would be great if you could check this out!

https://github.com/greenfork/nimraylib_now/releases/tag/v0.12.0

[greenfork]

Fixed the broken library build from yesterday, should be working now!

[greenfork]

I believe this issue is solved. Let me know if you still encounter some errors with conflicting windows.h file!