From: Vadim K. <va...@gm...> - 2007-03-26 15:12:20
|
I am trying to build clisp-2.41 using MSVC++ 6.0 I've read INSTALL file and followed the suggested instructions. My build is partially successfull: lisp.exe is created and it then used to produce further steps. But I get the system error in the following step of Makefile: lisp.exe -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -M interpreted.mem -q -c compiler.lisp I rerun this command with the following line: lisp.exe -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -M interpreted.mem -v -c compiler.lisp ..... ; (DEFUN PUSH-*DENV* (DECLSPECS) ...) ; (DEFSTRUCT (FNODE #) NAME ...) ; (DEFVAR *FUNC*) ; (DEFVAR *FUNC-START-LABEL*) ; (DEFVAR *ANONYMOUS-COUNT*) ; (DEFVAR *NO-CODE*) ; (DEFUN NOTE-FAR-USED-VAR (VAR) ...) ; (DEFUN NOTE-FAR-ASSIGNED-VAR (VAR) ...) ; (DEFUN NOTE-FAR-USED-BLOCK (BLOCK) ...) ; (DEFUN NOTE-FAR-USED-TAGBODY (TAGBODY+TAG) ...) ; (DEFUN PROPAGATE-FAR-USED (FNODE) ...) ; (DEFVAR *FORM*) ; (DEFVAR *FOR-VALUE*) ; (DEFSTRUCT (ANODE # #) TYPE ...) ; (DEFMACRO MAKE-ANODE (&KEY # TYPE ...) ...) ; (DEFSTRUCT (SECLASS #) (USES NIL :READ-ONLY ...) ...) ... and here system error arises thus failing the process. (lisp.exe has generated errors and will be closed by Windows...) Please advise me how can I fix this. BTW the INSTALL file in the 'win32msvc' directory is not consistent WRT different versions of MSVC and MSVCDIR environment variable. Should I suggest a patch fixing this? Vadim. |
From: Sam S. <sd...@gn...> - 2007-03-26 15:51:28
|
Vadim Konovalov wrote: > I am trying to build clisp-2.41 using MSVC++ 6.0 > ... and here system error arises thus failing the process. > (lisp.exe has generated errors and will be closed by Windows...) > > Please advise me how can I fix this. you need to compile a debug version (I think there is a win32*/makefile-*d for that) and run under debugger to see where the actual error lurks). note that you might get better results from mingw. > BTW the INSTALL file in the 'win32msvc' directory is not consistent > WRT different versions of MSVC and MSVCDIR environment variable. > Should I suggest a patch fixing this? sure, please do. |
From: Vadim K. <va...@gm...> - 2007-03-26 18:12:58
Attachments:
w32-install-diff.txt
|
Sam Steingold wrote: > Vadim Konovalov wrote: > >> I am trying to build clisp-2.41 using MSVC++ 6.0 > > >> ... and here system error arises thus failing the process. >> (lisp.exe has generated errors and will be closed by Windows...) >> >> Please advise me how can I fix this. > > > you need to compile a debug version (I think there is a > win32*/makefile-*d for that) and run under debugger to see where the > actual error lurks). I started debug session and, after quite long run debugger stopped at the same place where non-debuggung executable stopped. Please see the 300Kbytes screenshot at http://vkonovalov.ru/files-exchange/clisp-2.41-deb.error.jpg (sorry, I do not know how to place this information in text, but the screenshot is very obvious to read) > note that you might get better results from mingw. But MSVC is closer (more native) to windows, isn't it? I mean mingw uses some minimal emulation layer. Am I true that binary distribution of clisp on Woe32 made by mingw? > >> BTW the INSTALL file in the 'win32msvc' directory is not consistent >> WRT different versions of MSVC and MSVCDIR environment variable. >> Should I suggest a patch fixing this? > > > sure, please do. Atteched is my vision on this. Vadim. |
From: Sam S. <sd...@gn...> - 2007-03-26 19:09:33
|
Vadim Konovalov wrote: > Sam Steingold wrote: > >> Vadim Konovalov wrote: >> >>> I am trying to build clisp-2.41 using MSVC++ 6.0 >> >> >>> ... and here system error arises thus failing the process. >>> (lisp.exe has generated errors and will be closed by Windows...) >>> >>> Please advise me how can I fix this. >> >> >> you need to compile a debug version (I think there is a >> win32*/makefile-*d for that) and run under debugger to see where the >> actual error lurks). > > I started debug session and, after quite long run debugger stopped at > the same place where non-debuggung executable stopped. > > Please see the 300Kbytes screenshot at > http://vkonovalov.ru/files-exchange/clisp-2.41-deb.error.jpg > > (sorry, I do not know how to place this information in text, but the > screenshot is very obvious to read) "congratulations, I suppose"... you've got yourself corrupted memory. if you are lucky, this could be uncovered by a DEBUG_GCSAFETY build, see http://clisp.cons.org/impnotes/gc-safety.html if you are not that lucky, you will have to resort to "printf" grudge work. >> note that you might get better results from mingw. > > But MSVC is closer (more native) to windows, isn't it? > I mean mingw uses some minimal emulation layer. I don't think so (I think you are confusing cygwin with mingw). note that the mingw version is likely to be faster than the msvc version because clisp uses some assembly with gcc but not with msvc. note that we DO want CLISP to build with msvc, it's just that I have not seen a woe32 box for over a year now, so I cannot really debug anything. > Am I true that binary distribution of clisp on Woe32 made by mingw? "clisp -version" should tell you that. http://sourceforge.net/project/shownotes.php?release_id=455105&group_id=1355 contributed binary distributions: clisp-2.41-win32-mingw-without-readline.zip built by Jack Unrue <jd...@gm...> using mingw without i18n and readline with rawsock, dirkey, wildcard and bindings/win32 clisp-2.41-win32-with-readline-and-gettext.zip built by Yaroslav Kavenchuk <kav...@gm...> using mingw (with all 4 standard base modules) with rawsock, dirkey, wildcard and bindings/win32 looks like you are right - they are built with mingw. Sam. |
From: Vadim K. <va...@gm...> - 2007-03-28 18:14:13
Attachments:
lispbibl.d.diff.txt
|
> "congratulations, I suppose"... > you've got yourself corrupted memory. Seemingly this isn't exactly the memory corruption. Attached is the patch to fix it,. Some "Makefile" changes also needed in order to pass build stage, BTW. Eventually I'll send those also. > if you are lucky, this could be uncovered by a DEBUG_GCSAFETY build, see DEBUG_GCSAFETY works only for g++. MSVC++ do not compile some C++ code (some deeper C++ syntax-level deviation) > note that the mingw version is likely to be faster than the msvc > version because clisp uses some assembly with gcc but not with msvc. MAXIMA compiled with CLISP compiled with MSVC++ runs its run_testsuite() slower by a factor 2.+ May be this will make me rethink the whole situation :) :) :) Best regards, Vadim. |
From: Sam S. <sd...@gn...> - 2007-03-28 18:43:15
|
Vadim Konovalov wrote: > >> "congratulations, I suppose"... >> you've got yourself corrupted memory. > > > Seemingly this isn't exactly the memory corruption. > Attached is the patch to fix it,. > > --- lispbibl.d.orig 2006-10-12 04:05:23.000000000 +0400 > +++ lispbibl.d 2007-03-28 20:20:13.678558400 +0400 > /* the position of the last const (or doc or lalist!) */ > -#define Cclosure_last_const(obj) (Cclosure_length(obj) - 1 - \ > +#define Cclosure_last_const(obj) (Cclosure_length(obj) - \ > (sizeof(*(Cclosure)0) - offsetofa(srecord_,recdata))/sizeof(gcv_object_t)) does it pass all the test suites? (clisp, sacla, ansi)? this appears to change the meaning of the number from the last valid element to the position right behind it. also, please try the CVS head. Thanks. Sam. |
From: Vadim K. <va...@gm...> - 2007-03-28 19:00:28
|
Sam Steingold wrote: > Vadim Konovalov wrote: > >> >>> "congratulations, I suppose"... >>> you've got yourself corrupted memory. >> >> >> >> Seemingly this isn't exactly the memory corruption. >> Attached is the patch to fix it,. >> >> --- lispbibl.d.orig 2006-10-12 04:05:23.000000000 +0400 >> +++ lispbibl.d 2007-03-28 20:20:13.678558400 +0400 >> /* the position of the last const (or doc or lalist!) */ >> -#define Cclosure_last_const(obj) (Cclosure_length(obj) - 1 >> - \ >> +#define Cclosure_last_const(obj) (Cclosure_length(obj) - \ >> (sizeof(*(Cclosure)0) - >> offsetofa(srecord_,recdata))/sizeof(gcv_object_t)) > > > does it pass all the test suites? (clisp, sacla, ansi)? I only tried MAXIMA test suite :) :) , I'll try clisp test also. > this appears to change the meaning of the number from the last valid > element to the position right behind it. what do the code inside pr_cclosure_lang should have? Ok, I'll try changing macro usage within pr_cclosure_lang Vadim. |
From: Vadim K. <va...@gm...> - 2007-03-28 20:28:24
|
Sam Steingold wrote: > Vadim Konovalov wrote: > >> Sam Steingold wrote: >> >>> Vadim Konovalov wrote: >>> >>>> >>>> Attached is the patch to fix it,. >>>> >>>> --- lispbibl.d.orig 2006-10-12 04:05:23.000000000 +0400 >>>> +++ lispbibl.d 2007-03-28 20:20:13.678558400 +0400 >>>> /* the position of the last const (or doc or lalist!) */ >>>> -#define Cclosure_last_const(obj) (Cclosure_length(obj) - 1 >>>> - \ >>>> +#define Cclosure_last_const(obj) (Cclosure_length(obj) - \ >>>> (sizeof(*(Cclosure)0) - >>>> offsetofa(srecord_,recdata))/sizeof(gcv_object_t)) >>> >>> >>> does it pass all the test suites? (clisp, sacla, ansi)? >> >> >> >> I only tried MAXIMA test suite :) :) , I'll try clisp test also. > Indeed this isn't good patch: it cures MSVC++ build but GCC/Linux broke. As for running the tests, I can execute some of tests, but some I can't:. There are many tests to check some lisp program from command line, and command shell messes them,. So Makefile should be fixed for MSVC++. BTW Makefile assumes there are reasonable set of minimal commands - awk, sed, etc. Is it supposed to think that Perl is *not* among these? >> Ok, I'll try changing macro usage within pr_cclosure_lang > > > i think only one way is correct - if clisp passes all tests with your > patch, then we need a test that would fail either on cvs or with your > patch (or both :-) > Seemingly currently Cclosure_last_const is good, but MSVC++ unhappiness lies somewhere else. I'll let you know if I nail down this Best regards, Vadim. |
From: Sam S. <sd...@gn...> - 2007-03-28 20:38:44
|
Vadim Konovalov wrote: > As for running the tests, I can execute some of tests, but some I can't:. > There are many tests to check some lisp program from command line, and > command shell messes them,. > So Makefile should be fixed for MSVC++. note that makefiles are generated by src/makemake.in |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2007-03-30 18:33:14
|
Hi, >BTW Makefile assumes there are reasonable set of minimal=20 >commands - awk,=20 >sed, etc. Is it supposed to think that Perl is *not* among these? I'm sorry I can't help for my Samba server where I used to extract the sources has been down for month, but IIRC I explained in mswin/INSTALL how you can work around these programs (all you need is Emacs to perform a little search&replace). I've never bothered to install cygwin, yet in the past I managed to build clisp with MS-VC (version 5 or is it 6?). As a result, I'm quite happy when there are not many dependencies on weird UNIX (cygwin) tools, e.g. no perl. But I haven't looked at the current Makefile requirements for the last year, whether it added more dependencies. Regards, Jorg Hohle. |
From: Sam S. <sd...@gn...> - 2007-03-28 19:20:20
|
Vadim Konovalov wrote: > Sam Steingold wrote: >> Vadim Konovalov wrote: >>> >>> Attached is the patch to fix it,. >>> >>> --- lispbibl.d.orig 2006-10-12 04:05:23.000000000 +0400 >>> +++ lispbibl.d 2007-03-28 20:20:13.678558400 +0400 >>> /* the position of the last const (or doc or lalist!) */ >>> -#define Cclosure_last_const(obj) (Cclosure_length(obj) - 1 >>> - \ >>> +#define Cclosure_last_const(obj) (Cclosure_length(obj) - \ >>> (sizeof(*(Cclosure)0) - >>> offsetofa(srecord_,recdata))/sizeof(gcv_object_t)) >> >> does it pass all the test suites? (clisp, sacla, ansi)? > > > I only tried MAXIMA test suite :) :) , I'll try clisp test also. > >> this appears to change the meaning of the number from the last valid >> element to the position right behind it. > > what do the code inside pr_cclosure_lang should have? it should write all constants including the last one. > Ok, I'll try changing macro usage within pr_cclosure_lang i think only one way is correct - if clisp passes all tests with your patch, then we need a test that would fail either on cvs or with your patch (or both :-) PS. please do not CC me. I specifically set the "Reply-to" header to avoid copies. |
From: Vadim K. <va...@gm...> - 2007-03-26 20:06:50
|
>> I started debug session and, after quite long run debugger stopped at >> the same place where non-debuggung executable stopped. >> >> Please see the 300Kbytes screenshot at >> http://vkonovalov.ru/files-exchange/clisp-2.41-deb.error.jpg >> > "congratulations, I suppose"... > you've got yourself corrupted memory. > if you are lucky, this could be uncovered by a DEBUG_GCSAFETY build, see > http://clisp.cons.org/impnotes/gc-safety.html > if you are not that lucky, you will have to resort to "printf" grudge > work. this is tricky for me, as a novice in clisp. however, when looking closer into the MSVC debug session, the source of offending 0x00000a09 is in the pr_cclosure_lang (io.d) Lines near the call in the debugger show (please see my few [vk] comments) : .... (inside the pr_cclosure_lang function) .... var uintL pos = 0; var bool lambda_list_p = ccv_flags_lambda_list_p(ccv_flags); var bool documentation_p = ccv_flags_documentation_p(ccv_flags); var uintL end = last - lambda_list_p - documentation_p; if (end != (uintL)-1) [vk] the 'end' variable equals '-2' (rather 4294967294, or FFFFFFE) here and do not pass unequality check... [vk] isn't the source of the error? for (; true; pos++) { prin_object(stream_,TheCclosure(*obj_)->clos_consts[pos]); [vk] !!! the call above has 0x00000a09 as its 2nd argument; pos==1 at this moment... JUSTIFY_LAST(pos==end); if (pos==end) break; [vk] because (uintL)-2 is way too high the look will be for many iterations. JUSTIFY_SPACE; /* print one Space */ } ....... sorry if my vision is too naive. > > I don't think so (I think you are confusing cygwin with mingw). looking into output of 'clisp --version' I see lines gcc -mno-cygwin -O2 ..... -L/usr/local/lib /usr/local/lib/libiconv.a libcharset.a ... which makes me think that its easy to confuse mingw and cygwin :) :) > note that the mingw version is likely to be faster than the msvc > version because clisp uses some assembly with gcc but not with msvc. this makes much sence, thanks for the information. I had intentions to link with other LIBS already compiled by MSVC++, but, indeed, those could be compiled with different compilers. Thank you a lot for the provided help so far. Best regards, Vadim. |
From: Vadim K. <va...@gm...> - 2007-03-26 20:15:42
|
Vadim Konovalov wrote: > >>> I started debug session and, after quite long run debugger stopped >>> at the same place where non-debuggung executable stopped. >>> >>> Please see the 300Kbytes screenshot at >>> http://vkonovalov.ru/files-exchange/clisp-2.41-deb.error.jpg >>> >> "congratulations, I suppose"... >> you've got yourself corrupted memory. >> if you are lucky, this could be uncovered by a DEBUG_GCSAFETY build, see >> http://clisp.cons.org/impnotes/gc-safety.html >> if you are not that lucky, you will have to resort to "printf" grudge >> work. > > > > this is tricky for me, as a novice in clisp. > > however, when looking closer into the MSVC debug session, the source > of offending 0x00000a09 is in the pr_cclosure_lang (io.d) > > Lines near the call in the debugger show (please see my few [vk] > comments) : addition: lambda_list_p equals to 0 and documentation_p also equals 0 'last' receives -2 by the statement var uintL last = Cclosure_last_const(*obj_); *obj is seemingly okay... 'end' receives -2 because of this 'last' having -2 If this does not make obvious sence, okay, I'll try to figure out things in a slow way later... > > .... > (inside the pr_cclosure_lang function) > .... > var uintL pos = 0; > var bool lambda_list_p = ccv_flags_lambda_list_p(ccv_flags); > var bool documentation_p = ccv_flags_documentation_p(ccv_flags); > var uintL end = last - lambda_list_p - documentation_p; > if (end != (uintL)-1) > [vk] the 'end' variable equals '-2' (rather 4294967294, or FFFFFFE) > here and do not pass unequality check... > [vk] isn't the source of the error? > for (; true; pos++) { > prin_object(stream_,TheCclosure(*obj_)->clos_consts[pos]); > [vk] !!! the call above has 0x00000a09 as its 2nd argument; pos==1 at > this moment... > JUSTIFY_LAST(pos==end); > if (pos==end) break; [vk] because (uintL)-2 is way too high the > look will be for many iterations. > JUSTIFY_SPACE; /* print one Space */ > } > > ....... > > sorry if my vision is too naive. > >> >> I don't think so (I think you are confusing cygwin with mingw). > > > looking into output of 'clisp --version' I see lines > > gcc -mno-cygwin -O2 ..... -L/usr/local/lib /usr/local/lib/libiconv.a > libcharset.a > > ... which makes me think that its easy to confuse mingw and cygwin :) :) > > >> note that the mingw version is likely to be faster than the msvc >> version because clisp uses some assembly with gcc but not with msvc. > > > > this makes much sence, thanks for the information. > > I had intentions to link with other LIBS already compiled by MSVC++, > but, indeed, those could be compiled with different compilers. > > Thank you a lot for the provided help so far. > > Best regards, > Vadim. > > |
From: Sam S. <sd...@gn...> - 2007-03-26 20:17:24
|
Vadim Konovalov wrote: >>> I started debug session and, after quite long run debugger stopped at >>> the same place where non-debuggung executable stopped. >>> >>> Please see the 300Kbytes screenshot at >>> http://vkonovalov.ru/files-exchange/clisp-2.41-deb.error.jpg >>> >> "congratulations, I suppose"... >> you've got yourself corrupted memory. >> if you are lucky, this could be uncovered by a DEBUG_GCSAFETY build, see >> http://clisp.cons.org/impnotes/gc-safety.html >> if you are not that lucky, you will have to resort to "printf" grudge >> work. > > > this is tricky for me, as a novice in clisp. > > however, when looking closer into the MSVC debug session, the source of > offending 0x00000a09 is in the pr_cclosure_lang (io.d) > > Lines near the call in the debugger show (please see my few [vk] comments) : > > .... > (inside the pr_cclosure_lang function) > .... > var uintL pos = 0; > var bool lambda_list_p = ccv_flags_lambda_list_p(ccv_flags); > var bool documentation_p = ccv_flags_documentation_p(ccv_flags); > var uintL end = last - lambda_list_p - documentation_p; > if (end != (uintL)-1) > [vk] the 'end' variable equals '-2' (rather 4294967294, or FFFFFFE) here > and do not pass unequality check... > [vk] isn't the source of the error? > for (; true; pos++) { > prin_object(stream_,TheCclosure(*obj_)->clos_consts[pos]); > [vk] !!! the call above has 0x00000a09 as its 2nd argument; pos==1 at > this moment... > JUSTIFY_LAST(pos==end); > if (pos==end) break; > [vk] because (uintL)-2 is way too high the look will be for many iterations. > JUSTIFY_SPACE; /* print one Space */ > } > > ....... > > sorry if my vision is too naive. no, invalid slots (end=-2 &c) just means that the error is already behind us. i.e., the object in question is not really a function, so taking its ccv_flags &c does not make sense. you have to move up the stack and find the last object which makes sense, but whose slot does not. this is not likely to succeed though, because memory was corrupted during gc. I think DEBUG_GCSAFETY is your best bet here. >> I don't think so (I think you are confusing cygwin with mingw). > > looking into output of 'clisp --version' I see lines > > gcc -mno-cygwin -O2 ..... -L/usr/local/lib /usr/local/lib/libiconv.a > libcharset.a > > ... which makes me think that its easy to confuse mingw and cygwin :) :) "gcc -mno-cygwin" == mingw > Thank you a lot for the provided help so far. welcome! Sam. |