Hi, I want to build in Visual Studio 2019. I configured and generated on cmake with configuration you given. But when build in Vs2019, errors occures. What I do wrong. (I build zlib gmp and other libs on vcpkg)
If you are posting this question to me then I have to ask why are you not using VS 2022, it is free.
I have an vs2019 project. I bind swi prolog to my app. Some case app crashes because of Swi prolog. I want to debug it. So i need to build in visual studio.
Sorry I canāt be of more help. 
I donāt yet know how to build SWI-Prolog natively on Windows for Windows. My goal is to include the SWI-Prolog RocksDB interface, so for my task there is much more ground to cover before getting there.
It helps a lot if you include the first couple of errors and warnings. Now we can just guess. It would also help to specify the Prolog version (notably devel or stable). My guess is that the sources since then moved to the C11 standard as minimum (used to be C99). vs2019 does not do C11 by default. See How to enable C11 standard in VS 19??? - Microsoft Q&A
This may not be the only problem. Since then we use more GCC built-in functions for atomic and arithmetic operations. Hopefully most have replacements in VS. If you see undefined warnings for __builtin_<something>() that is what you are looking at. PRs welcome.
Thanks for helping. Actually, Iām getting some errors when binding SWI-Prolog from my app. In my case if application has console window than no problem when binding SWI-Prolog. But if app hasnāt console window than app crashes when binding SWI-Prolog. Is there any idea why Iām getting this problem?(Iām using 8.4.3 version)
Ah well, maybe the C11 requirement is handled by CMake 
Otherwise I donāt know. It does some fancy stuff making the console behave a bit. That should depend on whether or not there is a console. Possibly there is something wrong there. Without messages or a stack trace it is hard to say.
Thank you for helping.I will try to build
Hi again
I pull the top of master in swipl-devel repository. I solved some but still exist errors in Visual Studio 2022. I set the project configuration to C11 standard as you say. Did I miss something? Here is my cmake configuration and errors:(Build configuration: āDebug x64ā)
I pushed a patch (841ef37e3a317592e6585357c1270c309863582c) to swipl-devel.git that should avoid empty structs. Normally the compiler should optimize the resulting dummy away. At least on gcc it seems to make no measurable difference.
I pulled repository. Error fixed but new errors occured. Problem is based on VMH_GOTO macro.
Iāve pushed a number of patches to deal with tighter C11 conformance. The most notable issue is not being able to handle empty structures and array initialization (e.g., as in char argtypes[4] = {}). Empty declarations are a result of the C macros @dmchurch introduced to avoid the need make modifications in many places when changing the virtual machine instructions and to switch the VM between a giant C switch and a set of small functions. The work-around is to add a dummy field to these structs.
These changes allow for compilation using gcc -pedantic with most serious looking warnings gone.
The downside is that if we enable the work-arounds for gcc, performance drops by about 20% 
Now last time MSVC could compile the system it was already 30% slower than gcc ā¦
Some warnings remain under -pedantic, notably casting of functions pointers to/from void*. Some can be avoided, but for others this will get nasty. See 83584 ā "ISO C forbids conversion of object pointer to function pointer type" -- no, not really for a discussion on this topic.
Thanks for helping @jan. Most of errors are solved. Some errors still exist. I guess I solved some of them. Here is my corrections;(Iām not sure so I want to write) .
- First error āint32_tā: name in formal parameter list illegal and āuint32_tā: name in formal parameter list illegal in SWI-Prolog.h file.
int32_t and uint32_t definitions not exist so this cause errors.int64_t and uint64_t are defined already so I defined int32_t and uint32_t like them
#ifdef _MSC_VER
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
- Second error is ā__ATOMIC_ACQUIREā: undeclared identifier in pl-atom.c file.
#ifndef _MSC_VER
index = __atomic_load_n(&GD->atoms.highest, __ATOMIC_ACQUIRE);
#else
index = (size_t)InterlockedOrAcquire(&GD->atoms.highest, 0);
#endif
I found Atomic load in C with MSVC topic but Iām not sure this is the solution
- Other error is syntax error: missing ā)ā before identifier āPRId64ā in pl-write.c file. And this my correction;(For PRId64 Correction)
#ifdef _MSC_VER
#include <inttypes.h>
#endif
And there is my last errors;
C:\Projects\swipl-devel\src\os\pl-file.c(3960,1): error C2143: syntax error: missing ')' before '#'
C:\Projects\swipl-devel\src\os\pl-file.c(3960,1): error C2059: syntax error: ')'
C:\Projects\swipl-devel\src\os\pl-file.c(3960,11): error C2059: syntax error: ')'
C:\Projects\swipl-devel\src\pl-read.c(5283,1): warning C5101: use of preprocessor directive in function-like macro argument list is undefined behavior
C:\Projects\swipl-devel\src\pl-read.c(5285,1): error C2059: syntax error: '#'
C:\Projects\swipl-devel\src\pl-tabling.c(6016,1): warning C5101: use of preprocessor directive in function-like macro argument list is undefined behavior
C:\Projects\swipl-devel\src\pl-tabling.c(6029,1): error C2143: syntax error: missing ';' before '#'
C:\Projects\swipl-devel\src\pl-tabling.c(6029,1): error C2065: 'kvs': undeclared identifier
C:\Projects\swipl-devel\src\pl-tabling.c(6006,3): error C2223: left of '->accesses' must point to struct/union
C:\Projects\swipl-devel\src\pl-tabling.c(6031,3): error C2059: syntax error: 'return'
C:\Projects\swipl-devel\src\pl-tabling.c(6032,1): error C2059: syntax error: '}'
I vaguely recall this stuff was there because the old MSVC didnāt have <inttypes.h> at some point in the past. Pushed a fix that simply uses <inttypes.h> on all platforms. It is always a bit hard to decide when to drop #ifdef that deals with portability to old platforms
I guess it will do. One would expect there to be a load with acquire semantics, no? The link suggests not ā¦ but it is 5 years old. In this case it doesnāt matter much as long as the compiler is forced to actually reload from the address. Just doing a normal read caused some compilers to hold the value in a register, causing an infinite loop (according to git blame).
In general the interlocked operations for MSVC probably need reviewing. Some of them, notably in transaction handling are quite subtle and easy to get wrong.
It you use <inttypes.h> in SWI-Prolog.h, this should not be needed, I guess?
Pushed a fix for these.
For those like me scratching their head on acquire semantics
- In pl-debug.c
LNK2019 unresolved external symbol strncasecmp referenced in function get_next_debug_topic
I guess strncasecmp is works on Linux. _strnicmp maybe solve this error.
- In pl-stream.c
LNK2019: unresolved external symbol pclose referenced in function get_mode
LNK2019: unresolved external symbol popen referenced in function Sopen_pipe
pclose and pclose not working Windows. When I put the code(under) problem disappear.
#define popen _popen
#define pclose _pclose
Maybe there is more correct solution.
I think that is fine. Normally we use MinGW to compile on Windows. This provides a more functions by their POSIX name. Pushed updates for this. Also added an implementation for __atomic_load_n() that is good enough for our needs. Note that InterlockedOr64Acquire() on 64-bit Windows as size_t is 64 bits and long just 32 (on Windows).
Pushed more updates that makes the whole project compile without warnings using gcc -pedantic. 99% was avoiding GCC extensions, some of which made the code less pretty. Luckily this exercise also captured two real bugs. One of them I was a little surprised about. I had
if ( some_function > NULL ) ...
where the intend was
if ( some_function() > NULL )
I had hoped gcc would have warned on the above with ācondition always evaluates to trueā or something similar. It didnāt
1 Like
This does not seems a reasonable thing to do: you canāt do an ordered comparison with a null pointer, beside having undefined behavior, what is the aim?
I was wrong. The function returns an integer and the comparison is to 0. Also, it was not a condition, but a boolean expression to be returned. Still, the mistake was that I used the function (pointer) rather than the result of calling the function. Just a stupid typo, but I had hoped gcc would give some warning. Only using -pedantic it indeed comes with this
/home/janw/src/swipl-devel/src/pl-proc.c:1684:33: warning: ordered comparison of pointer with integer zero [-Wpedantic]
1684 | return clearBreakPointsClause >= 0;
| ^~
Anyway, it is fixed The bug only showed up when using debug breakpoints and the damage should be limited to an incorrect admin for existing breakpoints and some loss of memory.
2 Likes