From: Jeremy S. <sh...@go...> - 2005-08-16 16:24:37
|
Sam Steingold wrote: >>* Jeremy Shute <fuhgrw@tbbtyr.pbz> [2005-08-15 14:26:11 -0400]: >> >> >> >>>ffi: autoconf did not find dlopen and friends. >>> if you need that, you may want to investigate... >>> >>> >>> >>> >>I think on Cygwin you have to -ldl in order to get dlopen and friends. >>Is that being checked for in ./configure? >> >> > >works for me. >you can look at config.log to find out what went wrong for you. >see why HAVE_DLOPEN is not defined in your build/unixconf.h. > > I removed the directory and built a second time. configure:24884: checking for library containing dlopen configure:24914: gcc -o conftest.exe -g -O2 -I/usr/local/include conftest.c >&5 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot open output file conftest.exe: Device or resource busy collect2: ld returned 1 exit status configure:24920: $? = 1 There are several more "Device or resource busy" errors thereafter. This is probably due to the section right above it configure:24429: checking for working shared memory configure:24463: gcc -o conftest.exe -g -O2 -I/usr/local/include conftest.c >&5 configure:24466: $? = 0 configure:24468: ./conftest.exe configure: line 24469: 4908 Bad system call ./conftest$ac_exeext configure:24471: $? = 140 configure: program exited with status 140 >>>path: interesting. what does "mount" print? >>> >>> >>$ mount >>C:\cygwin\bin on /usr/bin type user (binmode) >>C:\cygwin\lib on /usr/lib type user (binmode) >>C:\cygwin on / type user (binmode) >>c: on /cygdrive/c type user (binmode,noumount) >> >>I don't know why those are mounted under /usr, quite honestly. Running >>ls in both and diffing the output shows it to be true, the contents of >>/bin and /usr/bin are identical. >> >>This was a fairly recent Cygwin install with a fairly recent setup.exe >>(like, last week). I didn't pull anything "funny", either, it came out >>of the box this way. >> >>I used "cygdrive" regularly as a prefix to get at other drives, so I >>know that works. >> >> > >CLISP DIRECTORY appears to be too smart for its own good and it gets >confused by the cygwin mounting tricks. > > So, you know what is wrong, here? Is there something else I can do in order to help you fix this? >>>streams: did you run the tests with a redirection? >>> >>> >>I did not run the tests with redirection. It failed during the >>./configure, then I changed directory to "build" and ran "make test" and >>it failed again. I wasn't using redirection in either case. >> >> > >you can try >$ ./configure --build build-g --with-debug >$ cd build-g >$ gdb lisp.exe >(gdb) boot >(gdb) run > > >>(CLEAR-INPUT *QUERY-IO*) >> >> >and see why it fails. > > $ gdb lisp.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... Breakpoint 1 at 0x428972: file eval.d, line 4937. Breakpoint 2 at 0x4262ea: file eval.d, line 4020. Breakpoint 3 at 0x422b89: file eval.d, line 2882. Breakpoint 4 at 0x42a48a: file eval.d, line 5905. Breakpoint 5 at 0x40c0be: file spvw_garcol.d, line 2430. Hardware watchpoint 6: back_trace Breakpoint 7 at 0x40f816: file spvw.d, line 657. Breakpoint 8 at 0x403d33: file spvw.d, line 479. Breakpoint 9 at 0x403ddb: file spvw.d, line 494. Breakpoint 10 at 0x4d82ca: file error.d, line 349. Breakpoint 11 at 0x4d825c: file error.d, line 326. Num Type Disp Enb Address What 1 breakpoint keep n 0x00428972 in funcall at eval.d:4937 xout fun 2 breakpoint keep n 0x004262ea in apply at eval.d:4020 xout fun 3 breakpoint keep n 0x00422b89 in eval at eval.d:2882 xout form 4 breakpoint keep n 0x0042a48a in interpret_bytecode_ at eval.d:5905 xout closure 5 breakpoint keep n 0x0040c0be in gar_col at spvw_garcol.d:2430 6 hw watchpoint keep n back_trace zbacktrace continue 7 breakpoint keep y 0x0040f816 in fehler_notreached at spvw.d:657 8 breakpoint keep y 0x00403d33 in SP_ueber at spvw.d:479 9 breakpoint keep y 0x00403ddb in STACK_ueber at spvw.d:494 10 breakpoint keep y 0x004d82ca in fehler at error.d:349 11 breakpoint keep y 0x004d825c in prepare_error at error.d:326 Function "sigsegv_handler_failed" not defined. .gdbinit:157: Error in sourced command file: No symbol "byteptr" in current context. (gdb) boot (gdb) run Starting program: /home/shutej/fcgi/clisp-head/clisp/build-g/lisp.exe -B . -N locale -M lispinit.mem -q -norc STACK depth: 16363 SP depth: 1073598755 [1]> (clear-input *query-io*) NIL [2]> What do you mean by "see why it fails"? I presume there's a reason why I'm running in GDB. Do you want me to set a breakpoint and examine any specific value inside the VM? Jeremy |