Yes. There are two major reasons at the moment:
0. The gthread and c11 thread use global BSTs to translate thread IDs to HANDLEs
upon *_join() or *_detach() calls, which would be problematic if mcfgthread is
linked
statically, since each dynamic library as well as the executable is going to
have
Hi, sorry for being so late.
I welcome a proper native thread implementation for windows gcc. I have one
point to address:
I like the fact that i can easily build static executables with mingw-w64.
In a few statements it was suggested that this will not be possible for
mcfgthread but i didn’t come
As a note, when I tried compiling gnutls today using "-march=native"
It failed, like
$ i686-w64-mingw32-gcc test.c -march=native
/var/folders/_s/c0kwjqxn2txglx5kdpcvmj0jb5h2bk/T//ccoQWGPg.o:test.c:(.text+0x1b):
undefined reference to `__sync_val_compare_and_swap_4'
collect2: error: ld returned
We've run into a similar issue cross-compiling fontconfig (mingw-w64 git)
demo:
$ cat test_mme.c
#define WIN32_LEAN_AND_MEAN
#include
//#include
int main(void) { MemoryBarrier(); return 1; }
$ ./sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc test_mme.c
$ ./sandbox/cross_compile
