Windows gcc shipped with choosenim 1.6.4 with TLS emulation turned off : The application was unable to start correctly (0xc000007b). Click OK to close the application #19713
Comments
creikey
changed the title
|
Cannot reproduce on win11 |
did you try compiling hello with |
|
Yeah, I testsed with echo "hello"
doAssert compileOption("threads") |
|
Because it's an issue with threads, I suspect it's some kind of path confusion with what threads dll it's linking with, but I have no idea how to check something like this... |
|
You could use |
Thanks for the troubleshooting tip Everything is ran like These are compiling the .o files, nothing weird here Here is the linking It looks like it's just linking the .o files it compiled earlier with no extra flags? What does --threads:on actually change? |
|
Diffing the generated C with threads on (left) vs threads off (right) This is the only difference in hello.c (from hello.nim) Similar results in the standard library compiled C NIM_THREADVAR is just this Apart from #include <stdio.h>
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && !defined __STDC_NO_THREADS__
# define NIM_THREADVAR _Thread_local
#elif defined _WIN32 && ( \
defined _MSC_VER || \
defined __ICL || \
defined __DMC__ || \
defined __BORLANDC__ )
# define NIM_THREADVAR __declspec(thread)
#elif defined(__TINYC__) || defined(__GENODE__)
# define NIM_THREADVAR
/* note that ICC (linux) and Clang are covered by __GNUC__ */
#elif defined __GNUC__ || \
defined __SUNPRO_C || \
defined __xlC__
# define NIM_THREADVAR __thread
#else
# error "Cannot define NIM_THREADVAR"
#endif
typedef char* NCSTRING;
typedef signed short int NI16;
typedef __int64 NI64;
typedef NI64 NI;
typedef struct TFrame_ TFrame;
struct TFrame_ {
TFrame* prev;
NCSTRING procname;
NI line;
NCSTRING filename;
NI16 len;
NI16 calldepth;
NI frameMsgLen;
};
# define N_LIB_PRIVATE
extern NIM_THREADVAR TFrame * framePtr__system_3025;
N_LIB_PRIVATE NIM_THREADVAR TFrame* framePtr__system_3025;
int main(int argc, char ** argv) {
printf("Hello\n");
}This compiles and runs fine |
|
MSVC compiler works with no issues |
|
It works on 1.6.0 |
|
Does the error only happen if using gcc as a backend? Could you tell which gcc you use with: If it's the mingw64 gcc provided by the nim website, try these others and see if the error persists: Also you can check with llvm/clang. |
|
@creikey can you compile on 1.6.4 with In 1.6.0, on Windows, it was standard to compile with |
|
@rockcavera it only happens when using gcc as a backend yes. I use the gcc shipped with choosenim, here is the gcc -v I tried tdm64 and it worked correctly without issues, like this: import os
proc threadFunc {.thread.} =
echo "From thread"
var myThread: Thread[void]
createThread(myThread, threadFunc)
sleep(500)Compiles and prints "From thread" Going back to the gcc which is broken, compiling with Works! With the CC environment variable being Without --tlsEmulation:on , it still crashes, so that fixes it. |
creikey
changed the title
|
Why does tlsEmulation:off break on my config in windows? It seems like it doesn't for others. @xflywind can you try compiling hello world with |
--tlsEmulation:off/on doesn't affect the threads on my PC. I use 21H2: 22000.556 |
That's a good question. I have no knowledge of how tlsEmulation works to answer you. But as it worked using tdm, I believe the mingw64 that nimble is installing, from winlibs.com, is linking some dll (maybe) that is corrupt. I once had a big battle with mingw64 from winlibs.com, as it doesn't statically link to glibc (at least when compiling a dll). Until I figured out the problem, when I tested tdm, I wasted almost a week. You could check between the executable with problem and the executable generated by tdm (which works without problem) the dlls that each one depends on with the Dependency Walker. Here, unfortunately, on Windows 10, I couldn't reproduce the problem. |
|
@xflywind |
|
Yeah, I installed it manually. |
|
@creikey Hi, is this issue related to libwinthread.dll? |
Yeah, I forgot I opened this issue but I figured out how to fix it for me, I added the bin folder in the choosenim mingw installation with the pthreads dll to my path and everything worked again. Windows is very helpful in not specifying at all what the problem is when you see an error like this. Nim should probably check for existence of the threads dll and warn the user if it can't find it instead of failing like this where it's not obvious what's wrong. |
|
This is a showstopper imo https://forum.nim-lang.org/t/9368. Seems to be a regression too? |
After switching to |
|
If we don't want an implicit dependency, maybe we should re-enable --tlsEmulation. #18146 was reopened. |
The problem actually lies with the mingw64 distribution that Nim uses, which prefers to dynamically link certain components. Depending on what you compile, there will even be a dependency on "libgcc_s_seh-1.dll", as that's what the maintainer of winlibs wanted. I'm not saying that winlibs is wrong, but it's a behavior I don't like. Edit: The problem has appeared in people who installed Nim with choosenim. Then choosenim should add to the Windows environment variable %PATH% the BIN folder of mingw64. |
|
As @rockcavera mentioned, there are some MinGW distributions that statically link winpthread and other similar libraries, such as https://jmeubank.github.io/tdm-gcc/ |
|
Would be awesome for Nim to ship that. |
oh yeah I just realized the binaries I ship too need those dlls to work, that sucks |
|
For what it's worth, choosenim specifically installs everything into This is just a workaround though, I don't think it's ideal for all Windows programs to have this runtime dependency. How difficult would it be to statically link this? |
|
I will have a try with |
…s + GCC config" (nim-lang#19119) (nim-lang#20327) * Revert "Remove tlsEmulation enabled from Windows + GCC config (nim-lang#19119) [backport:1.6]" This reverts commit 77b696c. * increase nimTlsSize to 48000 * enable for windows * fixes tests * fixes tlsEmulation:on
Hello world fails with this error:
The application was unable to start correctly (0xc000007b). Click OK to close the applicationbuilding with
nim r --threads:on hello.nimwithout --threads:on it works
with the file:
On windows 11 nim 1.6.4 on a fresh install
This worked on nim 1.6.0
I completely deleted .choosenim, .nimble, nimcache, cleared the path variables, then reinstalled nim once by downloading from the website, which didn't work, then again with choosenim, which also didn't work.
The text was updated successfully, but these errors were encountered: