opened
4lph4-Ph4un
username_0
Hi!

I have issue writing my first test with Criterion.

I have a very simple test definition for starters:

```C
#include <stdint.h>
#include <criterion/criterion.h>

Test(main, test) {
    cr_expect(strlen("Test") == 4, "Expected to be 4 chars long!");
}
```

Which gives the following build output:

```
clang -MTd -O3  -FC -I. -Isrc -Ilib -ID:/Projects/CnC++/Criterion/include \
        -c src/main.c -o obj/main.o
src/main.c:5:1: error: expected ';' after top level declarator
Test(main, test) {
^
D:/Projects/CnC++/Criterion/include\criterion/internal/test.h:197:37: note: expanded from macro 'Test'
#define Test(...)         CR_EXPAND(CR_TEST_BASE(__VA_ARGS__, .sentinel_ = 0))
                                    ^
D:/Projects/CnC++/Criterion/include\criterion/internal/test.h:178:49: note: expanded from macro 'CR_TEST_BASE'
        = &CR_IDENTIFIER_(Category, Name, meta) CR_SECTION_SUFFIX_;          \
                                                ^
D:/Projects/CnC++/Criterion/include\criterion/internal/common.h:71:14: note: expanded from macro 'CR_SECTION_SUFFIX_'
    __pragma(data_seg(pop))
```

The project is run on Windows 10 with Clang and MinGW enabled. The CMake build for Criterion didn't signal any errors as far as I can tell.
src/main.c:4:1: error: expected ';' after top level declarator
issue
created
Snaipe
username_1
Can you try to build the examples from your CMake build directory?

(run `cmake -DDEV_BUILD=ON -DCTESTS=ON <your-source-dir>` and then `cmake --build --target criterion_examples`)
comment
created
Snaipe
username_1
Re-reading this, something seems very wrong. Why is __pragma evaluated here? Is clang pretending to be MSVC?
comment
created
4lph4-Ph4un
username_0
Yeah! On Windows builds I have it to use MSVC!
comment
created
Snaipe
username_1
God damn it. If clang pretends to be a microsoft compiler, but fails to parse programs that are accepted by MSVC, then it's a compiler bug.

We can probably mitigate this here though. Does adding `#undef _MSC_VER` before `#include <criterion/criterion.h>` fix the compilation issues?
comment
created
4lph4-Ph4un
username_0
Hmm, true dat! undeffing _MSC_VER did remove the previous issue. Now somehow the build misses the entry point... ugghh.. these are the moments when MSVC makes my blood boil.

```
clang -MTd -O3  -FC -I. -Isrc -Ilib -ID:/Projects/CnC++/Criterion/include \
	-c src/main.c -o obj/main.o
clang obj/main.o -o build_win/C_master_class_tests.exe \
	 D:/Projects/CnC++/Criterion/build/Debug/criterion.lib -v
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
 "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64\\link.exe" -out:build_win/C_master_class_tests.exe -defaultlib:libcmt "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\lib\\amd64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.17763.0\\ucrt\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.17763.0\\um\\x64" -nologo obj/main.o D:/Projects/CnC++/Criterion/build/Debug/criterion.lib
LINK : fatal error LNK1561: entry point must be defined
clang.exe: error: linker command failed with exit code 1561 (use -v to see invocation)
```
comment
created
am11
username_2
Interesting to see MSVC link's  `/SUBSYSTEM:CONSOLE` there. According to docs, it should be the default: https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem#arguments.

Nonetheless, currently LLVM toolchain seems to be still picking up MSVC target for backend'ish processes, so the invocation expands to:

```sh
clang++ -fuse-ld=lld --target=x86_64-windows-msvc …
```

in order to force incur GNU'ism, e.g. toolchain installed via MinGW on system:

```sh
clang++ -fuse-ld=lld --target=x86_64-windows-gnu ...
```
comment
created
4lph4-Ph4un
username_0
```

But if I've understood correctly making gnu a target wouldn't really solve the issue, since the actual issue is that somehow clang is not unable to parse MSVC compatible library? It's kinda weird since I've been compiling and linking few MSVC based projects already and never gotten these type of errors. @username_1, do you think I should bring this up with the Clang folks?
comment
created
Snaipe
username_1
I think your environment might be broken -- I don't think that ld should be linking both the msvc CRT and the mingw CRT.
You might also be suffering from an inconsistent object file generation, where old object filed are generated with the win32 abi while you're linking the final program assuming the mingw abi. Make sure that criterion, your program, and your tests are all compiled from scratch with the same toolchain. I'd also try to feed the -fuse-ld flag in CFLAGS so that clang knows the target linker, although the linker choice should, in theory, only matter at the link command.
comment
created
4lph4-Ph4un
username_0
Yup! Seems likely! I'll look into it!
comment
created
am11
username_2
Yup, I'd set generator like in the CI script at root (`appveyor.yml`):

```powershell
#!/usr/bin/env powershell

mkdir Criterion/build
cd Criterion/build

# for VS2017, replace generator name with "Visual Studio 15 2017 Win64"
cmake .. -DCMAKE_BUILD_TYPE=Release -G="Visual Studio 14 2015 Win64"
cmake --build . --config Release

# note: for mingw toolchain, it would be:
# $env:MSYSTEM="MINGW64"; cmake .. -DCMAKE_BUILD_TYPE=Release -G="MSYS Makefiles"
comment
closed
4lph4-Ph4un
username_0
issue
created
4lph4-Ph4un
username_0
Thanks, this works! :)
comment