From: Sam S. <sd...@gn...> - 2016-05-13 21:37:00
|
> * Daniel Jour <qna...@tz...> [2016-05-12 03:25:49 +0200]: > > CLISP builds with libsigsegv, too. does GENERATIONAL_GC get enabled? > The tests run exactly the same as without libsigsegv: 2 errors for > tests/socket.tst and 3 for tests/path.tst. this is weird, I don't remember such failures. > Jörg wrote (regarding "64 bit support"): >> I'm confused. If on amd64, you're building a 64bit version, aren't you? >> So what doesn't get configured and what builds and passes tests? > > (on linux) > I'm on amd64, and am building a 64bit version. Both clisp and lisp.run are > 64bit elf executables. There's :WORD-SIZE=64 in *features*. (integer-length most-positive-fixnum) should return 48. > Instead of using defaults, I passed --without-ffcall, --without-dynamic-modules > and --without-readline (mostly out of curiosity). On linux amd64, this fails > with: > > (CHECK-OS-ERROR (SOCKET-SERVER 1240 :INTERFACE "[/]=") (:EINVAL 22)) > [OS-ERROR]: > *** - handle_fault error2 ! address = 0x0 not in [0x33437f000,0x3346e2dc0) ! > SIGSEGV cannot be cured. Fault address = 0x0. > > This looks a lot as if the message it's about to print isn't a valid > (C) string. yes, looks like it's a NULL pointer error. > Summarizing the configuration related stuff: > > * libsigsegv, ffcall, dynamic-modules, unicode, readline: yes > * threads, jitc: no > * disabling mmap on NetBSD is ok > * garbage collector / object representation: leave as is yes, but note platforms were you cannot build GENERATIONAL_GC. > * check that fixnums have 48 bits available on 64bit architectures (?) > * configuration system itself remains on TODO list for later > Ok, I'll try to bring some news regarding this ASAP. asdf should be updated > to it's recent version, right? (there was a post from its maintainer on > clisp-list: https://sourceforge.net/p/clisp/mailman/message/35010071/ ) yes > ./configure --help-modules > module sets found in the directory 'modules': > find: `modules': No such file or directory > to specify the location of external software: this is weird, never seen this. BTW, I suggest that you build in separate directories. (by passing dir arg to the top-level configure) > Sam wrote: >> You will have to update CLISP with 6 years worth of gnulib updates, and >> also figure out how to make it work on windows. >> This is the meat of the project. >> This is what the midterm eval will hinge on. > > Is there any "list" (possibly from the time of the first gnulib import) of > what gnulib module is imported for what reason? > In order to get anything to work on windows I'll find and fix that pathname > issues now. Makefile.devel is your friend. In a way, your only friend :-( Search for the word release there. > Finally: Do these mails get too long? Would it be better to split > further discussion by topic, i.e. windows-pathname related, My personal preference is for short emails with specific questions and clear subject lines. However, Jörg has an opposite preference, and, at any rate, it is really up to you. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 16.04 (xenial) X 11.0.11803000 http://www.childpsy.net/ http://mideasttruth.com http://thereligionofpeace.com http://dhimmi.org http://iris.org.il http://honestreporting.com If a train station is a place where a train stops, what's a workstation? |