OK, reporting back. :-) After some battling I have gotten Qt + MSVC + gprolog all to play nice. I've documented the lessons learned in the INSTALL file, and the other necessary changes to build files are also there, in this latest commit:
http://gitorious.org/ethex2040/ethex2040/commit/c737effd59e7b4d14e4042653c1c5a76e4c233fd Initially I thought I had a running app but somehow the wrong version of gplc was being called, and when the resultant object file was linked the prolog system could not find any predicates. The solution turned out to be an issue with msvc 2008 manifest files and the workaround is also documented in the INSTALL file<http://gitorious.org/ethex2040/ethex2040/blobs/master/INSTALL#line89>. In the future perhaps the gprolog build under msvc could take this into account. Now I'm basically back where I was with mingw, where the app compiles and runs, and calls into the prolog to initiate the logic, the prolog calls back out successfully with the initial report, but the more complex commands like "look" are failing. I have not yet put any time into debugging this so it may prove to be easy to fix with the different toolchain. On Sun, Mar 21, 2010 at 11:10 PM, Sarah Smith <[email protected]> wrote: > Following a suggestion off list I am trying a different toolchain - VC9, > which is a free download from Microsoft. As per the instructions for msvc > in the WINDOWS file I have also installed the platform SDK. That and mingw > are my only options for Qt on Windows so I hope it works. :-) > > Switching toolchains was not trivial. Much downloading and configuring and > a few minor glitches later I finally have a debug build of gprolog built > with Visual Studio C++ 2008. > > I had to comment out the line: > > #define fgetc getc > > in arch_dep.h to get around an error: > > c:\program files\microsoft visual studio 9.0\vc\include\stdio.h(272) : > error C3163: 'getc': attributes inconsistent with previous declaration > c:\program files\microsoft visual studio > 9.0\vc\include\stdio.h(214) : see declaration of 'getc' > > (( I guess the autoconf test was failing to set HAVE_FGETC )) > > Now I have to persuade Qt to use the VS tool chain... will report back. > > On Sat, Mar 20, 2010 at 10:11 PM, Sarah Smith <[email protected]> wrote: > >> Hi, >> >> First off would like to say thanks to the authors of gprolog for a great >> prolog implementation and an nice cross-platform distribution. >> >> I'm working on a text adventure game as a personal project, using prolog >> for the game logic, and C++/Qt for the UI. >> >> The plan is to release it on Mac (my main development platforrm), Windows >> (I run XP in a VM just for this purpose) and Linux. My day job is writing >> C++ code, and I know my way around compilers. >> >> As soon as I got past first base, with some game logic and a UI working, I >> wanted to build a release on all platforms to make sure things are all >> working. >> >> But while things work well on Mac - after a couple of teething problems - >> I'm stuck with a crash bug on Windows. >> >> The problem is occurring in my "do_command" function when I call >> Pl_Query_Call: >> >> extern "C" void do_command(const char *command) >> { >> int func; >> int res; >> PlTerm arg[512]; >> char cmd[512]; >> PlTerm list; >> >> func = Find_Atom("do_command"); >> >> if (func) >> { >> Pl_Query_Begin(PL_TRUE); >> i = 0; >> k = 0; >> list[0] = NULL; >> while (command[i]) >> { >> /* parse each token out into cmd */ >> arg[k++] = Mk_String(cmd); >> } >> if (k) >> list = Mk_Proper_List(k, arg); >> res = Pl_Query_Call(func, 1, list); >> while (res) >> res = Pl_Query_Next_Solution(); >> Pl_Query_End(PL_RECOVER); >> } >> } >> >> I've cut out some detail but the full source code is here: >> http://gitorious.org/ethex2040/ethex2040/blobs/master/prolog.cpp#line43 >> >> I compiled gprolog from source so I could use it in debug mode, but the >> stack trace is not helpful. At least it shows the site of the crash. >> >> When the above function processes a command, I get a SIGSEGV crash on line >> 69 of file unify.c in the function Pl_Unify: >> >> Bind_UV(u_adr, v_word) >> >> I presume there's something wrong with the u_adr pointer. But the other >> frames in the stack are assembler and so far I'm mystified as to how to >> trace what is going wrong. >> >> Any ideas? >> >> Regards, >> >> Sarah Smith >> > >
_______________________________________________ Users-prolog mailing list [email protected] http://lists.gnu.org/mailman/listinfo/users-prolog
