Re: Pl_Query_Call crash on windows (MacOSX OK)

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