Menu
▾
▴
clisp-devel
|
From: <don...@is...> - 2017-02-27 14:24:38
|
end of transcript showing first error: cd i18n ; make clisp-module CC="gcc -m64" CPPFLAGS="-I/home/don/hg/clisp/src -I/home/don/hg/clisp/build-dir/gllib -I/home/don/hg/clisp/src/gllib -I/home/don/hg/clisp/build-dir/gllib -I/home/don/hg/clisp/src/gllib" CFLAGS="-g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -fno-strict-aliasing -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_FFI -DDYNAMIC_MODULES -fPIC -DPIC" CLFLAGS=" -Wl,--export-dynamic" LIBS="libgnu.a -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a /usr/local/lib64/libsigsegv.a -lc " RANLIB="ranlib" CLISP="$CLISP -q" SHREXT=.so configure: creating cache config.cache configure: ** I18N (Common) checking how to remove colons from paths... echo $x checking for CLISP version... configure: error: '/home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc' is not a CLISP make[1]: Entering directory '/home/don/hg/clisp/build-dir/i18n' make[1]: *** No rule to make target 'clisp-module'. Stop. make[1]: Leaving directory '/home/don/hg/clisp/build-dir/i18n' Makefile:2262: recipe for target 'i18n' failed make: *** [i18n] Error 2 |
|
From: Bruno H. <br...@cl...> - 2017-02-27 15:39:37
|
Hi Don, > checking for CLISP version... configure: error: '/home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc' is not a CLISP This autoconf test merely runs the command with option '--version' and analyzes the output. So, what is the output of /home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version ? Bruno |
|
From: <don...@is...> - 2017-02-27 19:31:14
|
Bruno Haible writes: > Hi Don, > > > checking for CLISP version... configure: error: '/home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc' is not a CLISP > > This autoconf test merely runs the command with option '--version' and analyzes > the output. So, what is the output of > /home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version > ? $ /home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version STACK size: 98222 [0x7ffa8ed7ee00 0x7ffa8ecbf090] GNU CLISP 2.49+ (2010-07-17) (built 3697183652) (memory 3697183717) Software: GNU C 6.3.1 20161221 (Red Hat 6.3.1-1) gcc -m64 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -fno-strict-aliasing -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_FFI -DDYNAMIC_MODULES libgnu.a -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a /usr/local/lib64/libsigsegv.a -lc SAFETY=3 TYPECODES WIDE_HARD SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.10 libffcall 1.13 Features: (LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER LOGICAL-PATHNAMES SOCKETS GENERIC-STREAMS FFI GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX) C Modules: (clisp) Installation directory: /home/don/hg/clisp/build-dir/ User language: ENGLISH Machine: X86_64 (X86_64) number15.don-eve [10.0.2.150] |
|
From: Bruno H. <br...@cl...> - 2017-02-27 21:26:09
|
Don, Sam, > $ /home/don/hg/clisp/build-dir/clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version > STACK size: 98222 [0x7ffa8ed7ee00 0x7ffa8ecbf090] > GNU CLISP 2.49+ (2010-07-17) (built 3697183652) (memory 3697183717) > Software: GNU C 6.3.1 20161221 (Red Hat 6.3.1-1) > gcc -m64 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -fno-strict-aliasing -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_FFI -DDYNAMIC_MODULES libgnu.a -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a /usr/local/lib64/libsigsegv.a -lc > SAFETY=3 TYPECODES WIDE_HARD SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Thanks. I'm reproducing it through a build with CPPFLAGS="-DSAFETY=3 -DDEBUG_SPVW" but probably any options will do as well. The point is that we expect $ ./clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version 2>/dev/null | head -n 1 to be 1 line: "GNU CLISP 2.49+ (2010-07-17) (built 3697183652) (memory 3697183717)" but in fact it is the empty line. Here you see why: $ ./clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version 2>/dev/null | \ hexdump -e '"%06.6_ax " 16/1 "%02X "' -e '" " 16/1 "%_p" "\n"' "$@" 000000 0A 2A 2A 2A 20 2D 20 54 52 55 45 4E 41 4D 45 3A .*** - TRUENAME: 000010 20 54 68 65 20 76 61 6C 75 65 20 6F 66 20 2A 54 The value of *T 000020 45 52 4D 49 4E 41 4C 2D 49 4F 2A 20 77 61 73 20 ERMINAL-IO* was 000030 6E 6F 74 20 61 6E 20 61 70 70 72 6F 70 72 69 61 not an appropria 000040 74 65 20 73 74 72 65 61 6D 3A 20 23 3C 43 4C 4F te stream: #<CLO 000050 53 45 44 20 49 4F 20 54 45 52 4D 49 4E 41 4C 2D SED IO TERMINAL- 000060 53 54 52 45 41 4D 3E 2E 20 49 74 20 68 61 73 20 STREAM>. It has 000070 62 65 65 6E 20 63 68 61 6E 67 65 64 20 74 6F 0A been changed to. 000080 20 20 20 20 20 20 23 3C 49 4F 20 54 45 52 4D 49 #<IO TERMI 000090 4E 41 4C 2D 53 54 52 45 41 4D 3E 2E 0A 45 78 69 NAL-STREAM>..Exi 0000a0 74 69 6E 67 20 6F 6E 20 73 69 67 6E 61 6C 20 36 ting on signal 6 0000b0 0A . Sam, your turn, I guess. Bruno |
|
From: Sam S. <sd...@gn...> - 2017-03-02 02:13:05
|
Bruno, > * Bruno Haible <oe...@py...t> [2017-02-27 22:25:59 +0100]: > > Thanks. I'm reproducing it through a build with CPPFLAGS="-DSAFETY=3 -DDEBUG_SPVW" > but probably any options will do as well. The point is that we expect > > $ ./clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version 2>/dev/null | head -n 1 > > to be 1 line: > "GNU CLISP 2.49+ (2010-07-17) (built 3697183652) (memory 3697183717)" > but in fact it is the empty line. > > $ ./clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version 2>/dev/null | \ > hexdump -e '"%06.6_ax " 16/1 "%02X "' -e '" " 16/1 "%_p" "\n"' "$@" > 000000 0A 2A 2A 2A 20 2D 20 54 52 55 45 4E 41 4D 45 3A .*** - TRUENAME: > 000010 20 54 68 65 20 76 61 6C 75 65 20 6F 66 20 2A 54 The value of *T > 000020 45 52 4D 49 4E 41 4C 2D 49 4F 2A 20 77 61 73 20 ERMINAL-IO* was > 000030 6E 6F 74 20 61 6E 20 61 70 70 72 6F 70 72 69 61 not an appropria > 000040 74 65 20 73 74 72 65 61 6D 3A 20 23 3C 43 4C 4F te stream: #<CLO > 000050 53 45 44 20 49 4F 20 54 45 52 4D 49 4E 41 4C 2D SED IO TERMINAL- > 000060 53 54 52 45 41 4D 3E 2E 20 49 74 20 68 61 73 20 STREAM>. It has > 000070 62 65 65 6E 20 63 68 61 6E 67 65 64 20 74 6F 0A been changed to. > 000080 20 20 20 20 20 20 23 3C 49 4F 20 54 45 52 4D 49 #<IO TERMI > 000090 4E 41 4C 2D 53 54 52 45 41 4D 3E 2E 0A 45 78 69 NAL-STREAM>..Exi > 0000a0 74 69 6E 67 20 6F 6E 20 73 69 67 6E 61 6C 20 36 ting on signal 6 > 0000b0 0A . > > Sam, your turn, I guess. somehow gdb does not stop: (gdb) br main Breakpoint 20 at 0x106848: file ../src/spvw.d, line 3699. (gdb) run Starting program: /home/sds/src/clisp/current/build-g/lisp.run -M lispinit.mem |cat STACK size: 98222 [0x7ffff7f81e00 0x7ffff7ec2090] *** - TRUENAME: The value of *TERMINAL-IO* was not an appropriate stream: #<CLOSED IO TERMINAL-STREAM>. It has been changed to #<IO TERMINAL-STREAM>. During startup program exited normally. (gdb) this: (gdb) run -M lispinit.mem 2>/dev/null stops on breaks, but does not fail with the "not an appropriate stream" error. ideas? -- Sam Steingold (http://sds.podval.org/) on Ubuntu 16.10 (yakkety) X 11.0.11804000 http://www.childpsy.net/ http://memri.org http://ffii.org http://dhimmi.org http://www.dhimmitude.org http://americancensorship.org MS: our tomorrow's software will run on your tomorrow's HW at today's speed. |
|
From: Sam S. <sd...@gn...> - 2017-03-05 22:10:52
|
Bruno, We have a problem, yet another case where the CL universe is different from UNIX (and, probably, Windows, but I don't have access to that, so, thankfully, I can excuse myself): * CL assumes that (truename open-file-stream) works * on unix, "/dev/fd/0" resolves to "/proc/<pid>/fd/0" which is a symlink to "pipe:[123456789]" when the process is run like "clisp | cat". (and the "/proc/<pid>/fd/pipe:[...]" file does not exist). IOW, on unix one can do i/o on a non-existent path (sometimes). What to do about it? * We can detect that "/proc/<pid>/fd/0" is on "/proc" and refuse to follow symlinks there. This is fairly arbitrary, but we already use this sort of magic when deciding the default value for the :buffered argument. This would also prevent users from detecting that the stdout is a path (not good). [btw, shouldn't we treat /proc and /dev identically? neither is a real file system]. * We can defer computing strm_file_truename until necessary, leading to various special cases for (open (make-stream :input)) (which will call truename) &c. I don't particularly like either approach; but I think I dislike the first one less. Other ideas? > * Bruno Haible <oe...@py...t> [2017-02-27 22:25:59 +0100]: > > $ ./clisp -K boot -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc --version 2>/dev/null | \ > hexdump -e '"%06.6_ax " 16/1 "%02X "' -e '" " 16/1 "%_p" "\n"' "$@" > 000000 0A 2A 2A 2A 20 2D 20 54 52 55 45 4E 41 4D 45 3A .*** - TRUENAME: > 000010 20 54 68 65 20 76 61 6C 75 65 20 6F 66 20 2A 54 The value of *T > 000020 45 52 4D 49 4E 41 4C 2D 49 4F 2A 20 77 61 73 20 ERMINAL-IO* was > 000030 6E 6F 74 20 61 6E 20 61 70 70 72 6F 70 72 69 61 not an appropria > 000040 74 65 20 73 74 72 65 61 6D 3A 20 23 3C 43 4C 4F te stream: #<CLO > 000050 53 45 44 20 49 4F 20 54 45 52 4D 49 4E 41 4C 2D SED IO TERMINAL- > 000060 53 54 52 45 41 4D 3E 2E 20 49 74 20 68 61 73 20 STREAM>. It has > 000070 62 65 65 6E 20 63 68 61 6E 67 65 64 20 74 6F 0A been changed to. > 000080 20 20 20 20 20 20 23 3C 49 4F 20 54 45 52 4D 49 #<IO TERMI > 000090 4E 41 4C 2D 53 54 52 45 41 4D 3E 2E 0A 45 78 69 NAL-STREAM>..Exi > 0000a0 74 69 6E 67 20 6F 6E 20 73 69 67 6E 61 6C 20 36 ting on signal 6 > 0000b0 0A . > > Sam, your turn, I guess. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://www.dhimmitude.org http://iris.org.il http://no2bds.org http://camera.org https://ffii.org Life is like Tetris: failures accumulate, successes fade. |
|
From: Bruno H. <br...@cl...> - 2017-03-06 00:28:46
|
Hi Sam, > We have a problem, yet another case where the CL universe is different > from UNIX (and, probably, Windows, but I don't have access to that, so, > thankfully, I can excuse myself): > > * CL assumes that (truename open-file-stream) works Yes and no. CL says that it is OK to call (truename open-file-stream). [See http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_truename.html The argument is a 'pathname designator'. The glossary says that this includes 'stream associated with a file', and 'stream associated with a file' includes 'file stream'.] CL also says that the call may fail. [Exceptional Situations: An error of type file-error is signaled if an appropriate file cannot be located within the file system for the given filespec, or if the file system cannot perform the requested operation.] Cases where TRUENAME fails, on Unix, are when you have read and search access to the current directory but not to one of the ancestor directories. > * on unix, "/dev/fd/0" resolves to "/proc/<pid>/fd/0" which is a symlink > to "pipe:[123456789]" when the process is run like "clisp | cat". > (and the "/proc/<pid>/fd/pipe:[...]" file does not exist). > IOW, on unix one can do i/o on a non-existent path (sometimes). Yes, I can reproduce this: $ ./clisp -norc -q -x '(truename "/dev/fd/1")' #P"/dev/pts/9" $ ./clisp -norc -q -x '(truename "/dev/fd/1")' | cat *** - TRUENAME: File #P"/proc/872/fd/pipe:[3163863]" does not exist > What to do about it? > > *1* We can detect that "/proc/<pid>/fd/0" is on "/proc" and refuse to > follow symlinks there. > This is fairly arbitrary, but we already use this sort of magic when > deciding the default value for the :buffered argument. > This would also prevent users from detecting that the stdout is a > path (not good). > [btw, shouldn't we treat /proc and /dev identically? neither is a real > file system]. > > *2* We can defer computing strm_file_truename until necessary, leading to > various special cases for (open (make-stream :input)) (which will call > truename) &c. > > I don't particularly like either approach; but I think I dislike the > first one less. You need both. You need *1* because the two commands I gave above show that the problem already occurs when streams are not involved. You need *2* because no one has asked to compute the truename ahead of time, when the stream is being created. More details about *1*: When the symlink chain is /dev/fd/1 -> /proc/self/fd/1 -> /dev/pts/9 I want to get "/dev/pts/9" as result. Whereas when the symlink chain is /dev/fd/1 -> /proc/self/fd/1 -> pipe:[3163863] or /dev/fd/1 -> /proc/self/fd/1 -> socket:[2881830] I want to get "/proc/self/fd/1" as result, because you can't do anything with the internal inode number of the pipe or socket. Therefore it's only some of the symlinks in /proc that you need to refuse to follow. /dev is, like autofs, binfmt_misc, cgroup, debugfs, devtmpfs, efivarfs, fusectl, hugetlbfs, mqueue, proc, pstore, securityfs, sysfs, tmpfs, tracefs (and sure some others) a synthetic file system, that is, a file system not backed by a disk. But its symlinks are OK, as far as I have seen. So I would leave /dev alone until we see that it has problems. More details about *2*: Following these links in the hyperspec http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_truename.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/glo_p.html#pathname_designator http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/glo_s.html#stream_associated_with_a_file http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/glo_f.html#file_stream http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/syscla_file-stream.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_open.html I cannot see a wording that indicates that the truename needs to be stored in the stream. Rather it looks like the stream is supposed to store the (not canonicalized) pathname to which it was associated when it was created, and the TRUENAME function will canonicalize it when TRUENAME is called. It it harmful to call TRUENAME ahead of time because the user has not asked for it when he creates a stream, and: - TRUENAME may fail (see above), - File systems nowadays are optimized so that very few operations need to canonicalize a file name. This canonicalization is expensive, even when done through a kernel API [1]. In particular $ ./clisp -norc -q -x '(open "/dev/fd/1")' | cat *** - OPEN: File #P"/proc/1040/fd/pipe:[3172140]" does not exist is wrong. The correct output would be $ ./clisp -norc -q -x '(open "/dev/fd/1")' | cat #<INPUT UNBUFFERED FILE-STREAM CHARACTER #P"/dev/fd/1" @1> Bruno [1] http://stackoverflow.com/questions/1188757/getting-filename-from-file-descriptor-in-c |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X