Building cln-1.1.13 has a few nice improvements, but there were a few build problems that required adjustments and reruns. In summary, these facts are notable about the build process: 1. Configure ran in only about two minutes, and it was nice to note that the old misleading problem with "checking whether make sets $(MAKE)" was gone and in its place was a nice, unconfusing "... yes".] 2. The compile failure for "cl_random_from.cc" is now gone and the library builds nicely thanks in part, apparently, to patch(es) from Sheplyakov Alexei. 3. The "--disable-shared" option for configure seems desirable in a cygwin/mingw environment, and in fact it seems a good idea for a distributed version of CLN to make "--disable-shared" an automatic default in such an environment. 4. The default value "/usr/bin/install -c" (without quotes) for INSTALL in the Makefiles will cause "make install" for doc/Makefile to crash. An appropriate command-line override for INSTALL appears necessary. 5. The problem with "Illegal number syntax" at test "test_I_io" is still present. 6. Is seems that all executables (.exe) get rebuilt when make is rerun, regardless of whether changes have been made to dependent files. In particular, it seems that the Makefiles do not correctly specify the extension .exe as part of the dependency information for the executables. For example, "exam" (not "exam.exe") is listed as part of the value for PROGRAMS in tests/Makefile, and $(PROGRAMS) is provided as a (collective) target for building excutables with $(LIBTOOL_LINK); so it appears that make looks for the file "exam" rather that "exam.exe" in deciding whether to rebuild "exam.exe" (which it "thinks" is "exam"); since there is generally no file "exam", "exam.exe" always gets rebuilt. This consideration appears to apply to the executables in directories "examples" and "benchmarks" as well.) My initial configure command was: CC=C:/Dev-Cpp/bin/gcc CFLAGS="-O2 -finline-limit=1000 -fno-exceptions" CXX=C:/Dev-Cpp/bin/g++ CXXFLAGS="-O2 -finline-limit=1000 -fno-exceptions" INSTALL="C:/cygwin/bin/install -c" ./configure --disable-shared --prefix=C:/gnu/cln-1.1.13/gcc342 &> config_out.txt but without the INSTALL=... argument and without the --disable-shared option. I did the CLN build without using the "--disable-shared" option because I wanted to double-check the likelihood that no DLLs would be produced. Evidently, DLLs won't be produced in a cygwin/mingw environment. (See http://www.cebix.net/pipermail/ginac-list/2006-July/000865.html in regard to no DLLs for GiNaC; it seems the same considerations apply to CLN as well. See also documentation for "a2dll" (for converting static libraries to DLLs) in the "mingw-utils-0.3.tar.gz" distribution. But note also that the readline build does produce DLLs. So, from this test and the situation with GiNaC builds vis-a-vis DLLs, it seems advisable that the "--disable-shared" option should also be used in a cygwin/mingw environment in order to eliminate the unnecessary duplicate build of objects for a shared library. Perhaps configure should be modified (in a future distribution) to provide this option as a default for a cygwin/mingw environment. Apparently, by the "a2dll" documentation, even if someone were industrious enough to produce a DLL for CLN, there is no need for separate object modules anyway in a win32 environment. So even if DLL-building were supported in this environment, very likely only one object module per C++ source module would need to be built.) Thus, my preference would be to add the "--disable-shared" option (for the current cln-1.1.13) as shown above. After correcting a problem with an inappropriate version of rm.exe vis-a-vis "hidden" .lnk extensions (problem solved by rearranging the order of directories in my PATH variable) and restarting from scratch, "make" took an hour and 14 minutes to run (compiling a "shared" and a "static" version of object modules for each source module). So it appears that configure's "--disable-shared" option would definitely be useful. I then ran "make check" and encountered the problem with "Illegal number syntax" at test "test_I_io", as I did with previous builds of CLN. I then commented out the test "test_I_io" in tests/test_I.cc and reran "make check" again, which not only rebuilt test_I.o and test.exe, but seems to have also rebuilt all the other executables (.exe), in directories tests , examples , and benchmarks . It seems that the Makefiles probably do not correctly specify the extension .exe as part of the dependency information for the executables. The resulting "make check" ran without error. I then ran "make install", but found that make produced the following error message while processing in directory doc: /usr/bin/install -c -m 644 ./cln.info C:/gnu/cln-1.1.13/gcc342/share/info/cln.info process_begin: CreateProcess((null), /usr/bin/install -c -m 644 ./cln.info C:/gnu/cln-1.1.13/gcc342/share/info/cln.info, ...) failed. make (e=3): The system cannot find the path specified. c:\Dev-Cpp\bin\make.exe[1]: *** [install] Error 3 So I reran the configure command line again, but this time with the INSTALL=... argument as specified in the command line given above (but without the "--disable-shared" option). And then I reran "make install" again and this time it ran to completion without errors (determined by searching for the string "error" without case limitations). System specs: OS: Microsoft Windows XP Home Edition gcc: gcc version 3.4.2 (mingw-special) ld: GNU ld version 2.15.91 20040904 installer package (for mingw tools): devcpp-4.9.9.2_setup.exe _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash : GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.13 computer: Dell Inspiron 2650 processor: x86 Family 15 Model 2 Stepping 7 GenuineIntel ~1495 Mhz total physical memory (RAM): 384.00 MB Best regards, Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com