I don't remember having that problem with pathnames. Maybe we are using different configuration, so different code path is executed. Mine ECL is configured like this:
./configure CFLAGS="-Ic:/usr/local/include -Ic:/usr/local/lib/libffi-3.0.9/include" LDFLAGS="-Lc:/usr/local/lib" --prefix=c:/opt/ecl --enable-threads --enable-unicode --with-system-gmp -enable-boehm=system I can't tell you the correct version where I'm currently using since lisp-implementation-version returns "11.1.1" without info about git tree. I'm not able to build ecl from latest git sources right now, so I can't check with current version. I'm getting the following error when building ecl. if test -f ../CROSS-DPP ; then ../CROSS-DPP /c/development/cvstree/ecl/src/c/threads/process.d tmp.c ; else ./dpp.exe /c /development/cvstree/ecl/src/c/threads/process.d tmp.c ; fi dpp: c:/development/cvstree/ecl/src/c/threads/process.d -> tmp.c Unknown symbol: si::*interrupts-enabled* Unknown symbol: si::*interrupts-enabled* Unknown symbol: si::*interrupts-enabled* gcc -DECLDIR="\"c:/opt/ecl/lib/ecl-11.1.1\"" -I. -Ic:/development/cvstree/ecl/build -I/c/development/cvstree/ecl/src/c - I../ecl/gc -DECL_API -DECL_NO_LEGACY -Ic:/usr/local/include -Ic:/usr/local/lib/libffi-3.0.9/include -D_THREAD_SAFE - Dmingw32 -c -o threads/process.o tmp.c c:/development/cvstree/ecl/src/c/threads/process.d: In function 'mp_block_signals': c:/development/cvstree/ecl/src/c/threads/process.d:606:47: error: 'unknown' undeclared (first use in this function) c:/development/cvstree/ecl/src/c/threads/process.d:606:47: note: each undeclared identifier is reported only once for ea ch function it appears in c:/development/cvstree/ecl/src/c/threads/process.d: In function 'mp_restore_signals': c:/development/cvstree/ecl/src/c/threads/process.d:612:9: error: 'unknown' undeclared (first use in this function) make[2]: *** [threads/process.o] Error 1 make[2]: Leaving directory `/c/development/cvstree/ecl/build/c' make[1]: *** [libeclmin.a] Error 2 make[1]: Leaving directory `/c/development/cvstree/ecl/build' make: *** [all] Error 2 Regards, Marko Kocić On Sun, Mar 6, 2011 at 11:59 PM, Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote: > > > On Mon, Feb 28, 2011 at 11:52 AM, Marko Kocić <marko.ko...@gmail.com> wrote: >> >> > I am a bit puzzled. Is this very recent? >> >> Not that recent. It happens from time to time. At first only in SLIME, >> but now it fails frequently on the command line too. >> Reliable way to trigger it is to try to quickload, for example >> closure-html, but it happens also on other libraries. > > I tried to check whether closure-html really produces infinite loops in the > type propagator but I am unable to even start building it. It seems they > have some bogus pathnames there, because I get (with the new error rmessage > in CVS) something like > Condition of type: SIMPLE-ERROR > Pathname without a physical namestring: > :HOST NIL > :DEVICE NIL > :DIRECTORY (ABSOLUTE Users jjgarcia quicklisp dists quicklisp software > closure-html-20101006-git resources dtd) > :NAME Entities-Latin1 > :TYPE UNSPECIFIC > :VERSION NEWEST > Could you verify? It is unsupported to have :unspecific components in > pathnames. > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list