I'm trying to cross-compile from Linux to Windows using the latest mingw toolchain on Ubuntu 20.04. My application imports nim-json-rpc's rpcclient and rpcserver which have a dependency on nim-bearssl. nim-bearssl is a wrapper for the C lib bearssl.
I compile the program with the mingw toolchain: nim c -d:mingw --cpu:amd64 rpchandler.nim
The error looks like Linux is not parsing the C file path correctly, and it complains that the bearssl src files are not found. I'm not sure how to proceed with troubleshooting this error.
Appreciate any help I can get.
Here's the error:
Hint: used config file '/etc/nim/nim.cfg' [Conf]
Hint: used config file '/etc/nim/config.nims' [Conf]
...............................................................................................................................CC: decls.nim\csources\src\codec\ccopy
CC: decls.nim\csources\src\codec\dec16be
CC: decls.nim\csources\src\codec\dec16le
CC: decls.nim\csources\src\codec\dec32be
x86_64-w64-mingw32-gcc: error: /home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/decls.nim\csources\src\codec\ccopy.c: No such file or directory
x86_64-w64-mingw32-gcc: fatal error: no input files
compilation terminated.
CC: decls.nim\csources\src\codec\dec32le
CC: decls.nim\csources\src\codec\dec64be
x86_64-w64-mingw32-gcc: error: /home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/decls.nim\csources\src\codec\dec16be.c: No such file or directory
x86_64-w64-mingw32-gcc: fatal error: no input files
compilation terminated.
Error: execution of an external compiler program '/usr/bin/x86_64-w64-mingw32-gcc -c -w -fmax-errors=3 -mno-ms-bitfields -DWIN32_LEAN_AND_MEAN -I/home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/decls.nim\csources\src -I/home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/decls.nim\csources\inc -I/home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/decls.nim\csources\tools -DBR_USE_WIN32_TIME=1 -DBR_USE_WIN32_RAND=1 -DBR_LE_UNALIGNED=1 -DBR_64=1 -DBR_amd64=1 -DBR_INT128=1 -I/home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/cacert.nim\certs -I/usr/local/lib/nim -I/home/VVX7/Nim/rpc_stuff/module/handler/rpcmod -o '/home/VVX7/.cache/nim/rpchandler_d/decls.nim\csources\src\codec\ccopy.c.o' '/home/VVX7/.nimble/pkgs/bearssl-0.1.5/bearssl/decls.nim\csources\src\codec\ccopy.c'' failed with exit code: 1
Yep, the csources are there.
I'm new to MinGW so I'm not sure how to fix that path issue. If this were a case of MinGW incorrectly building a path then I would expect it to be a common problem for anyone cross-compiling with a wrapped c library. Unfortunately I'm not turning up more info on what might be happening here.
When using 3rd party libraries I got repeatedly stuck due to this extremely annoying issue. Everything in the code is right, but the path separators are wrong for cross-compilation. This happened so many times now and I do not know how to solve this problem for every library.
I've searched for solutions to force no conversion of path separators at all, yet none worked. The only half-way reliable workaround I found is rewriting all paths with literal strings, though even that does not work sometimes and it is certainly a lot of work, every time.
Is there no known actual solution that forces the path separators to stay as slashes and not convert to backslashes?
This is a true cross-compilation nightmare, that I need to get rid off....!
I tried to cross-compile something to Windows with the same command and have a similar issue:
fatal error: \home\grfork\reps\nimraylib_now\src\nimraylib_now\raylib.h: No such file or directory
from os import parentDir, `/`
const raylibHeader = currentSourcePath().parentDir()/"raylib.h"
In my case all the slashes are backwards because it used windows convention for slashes while I'm on linux. So I assume it might be a library issue. And I don't know how to solve it since Nim doesn't have the notion of "host" and "target" systems.
And I don't know how to solve it since Nim doesn't have the notion of "host" and "target" systems.
If you urgently need a workaround:
You need to go into the offending library and replace all joinPath() or / (the alias for joinPath()) calls with the absolute path from your machine. It's a crappy method, but it works!
I hope it helps.