Getting Qt to play ball was no problem. But now I have more problems with gprolog.
This is a lot harder than I feel it should be. Ok - current problem is now that msvc will not link the application: link /LIBPATH:"c:\msys\1.0\local\gprolog-1.3.1\lib" /LIBPATH:"c:\Qt\4.6.2\lib" /NOLOGO /DEBUG /MANIFEST /MANIFESTFILE:"debug\ethex2040.intermediate.manifest" /SUBSYSTEM:WINDOWS "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /OUT:debug\ethex2040.exe @C:\develop\tmp\ethex2040.exe.20176843.jom libbips_pl.a(error_supp.o) : warning LNK4078: multiple '.stab' sections found with different attributes (42300000) libbips_pl.a(error_supp.o) : warning LNK4078: multiple '.stabstr' sections found with different attributes (42100000) libbips_pl.a(arith_inl_c.o) : error LNK2019: unresolved external symbol _rint referenced in function _Pl_Fct_Round libbips_pl.a(os_interf_c.o) : error LNK2019: unresolved external symbol __alloca referenced in function _Pl_Spawn_3 libengine_pl.a(engine1.o) : error LNK2001: unresolved external symbol __alloca debug\ethex2040.exe : fatal error LNK1120: 2 unresolved externals What I don't understand is why _rint is appearing there, or why alloca is being used. In arith_inl_c.c I see #define rint(x) (floor((x) + (double) 0.5) and inserting a #error hi mum in front of the #define confirms that this "rint" is being defined to be floor - but somehow its still appearing as a symbol in libbips_pl.a. alloca is IIRC a gcc symbol - why this is being used in libbips_pl and libengine_pl with msvc I don't know. 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
