-
Notifications
You must be signed in to change notification settings - Fork 16
Building conflicts with windows.h for some users #5
Comments
ill try to use nimraylib_now every once in a while to see if i can understand the issue |
Alright, thanks! Let me know if you have some ideas or anything, we can brainstorm it together |
I just had this problem. Here's what I did: # Creating an empty sequence like this gives a compilation error:
var mySeq = newSeq[Vector2]()
Same thing happens with
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. |
@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 raysan5/raylib#1217 |
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.
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. |
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 What I did to solve this is simply rename all the conflicting functions. For example, this file WINGDIAPI WINBOOL WINAPI Rectangle(HDC hdc,int left,int top,int right,int bottom); I renamed it to 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. |
@RecruitMain707 @Intasx @XDEmer0r-L0rd-360-G0d-SlayerXD hi! I tried to fix the windows.h conflict with this branch: Your general approach should be something like this, in command line:
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: #9 |
Hey! Sorry for the late reply. Sadly it still doesn't work, I got the same errors :( I think this is the problem: /* 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" |
Discussion on Nim forum: https://forum.nim-lang.org/t/7950 |
upstream is familiar with this issue, as you'd imagine: raysan5/raylib#857 you could just edit the raylib header, no? as done here: |
@shirleyquirk thanks for suggestions!
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
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. |
@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! |
Fixed the broken library build from yesterday, should be working now! |
I believe this issue is solved. Let me know if you still encounter some errors with conflicting |
This is only relevant for SOME Nim installations, so far no clue why.
raysan5/raylib#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.
The text was updated successfully, but these errors were encountered: