When I first tried building CLN and GiNaC a few years ago, I got a message from the configure script similar to the following, which is the typical output in the most recent builds: <begin quote> checking whether make sets $(MAKE)... ./configure: eval: line 1: unexpected EOF while looking for matching `"' ./configure: eval: line 2: syntax error: unexpected end of file no <end quote> Sheplyakov Alexei's recent comments about building without modifying Makefiles and my most recent tests seem to show that this error message does not indicate a fatal error for the build process, but merely indicates an "error" that is a "normal" result of the test and whose potential ill consequences the configure script is quite able to circumvent. So when I first tried building CLN & GiNaC a few years ago, I think I probably got a configure failure because readline headers and/or binary library (libreadline.a) could not be found and/or because the CLN library could not be found. So when I found that configure did not produce results that would allow an error-free build, I, as a newbie to the process, began perusing all of the output to see if I could find some clear indication as to why the build was failing. The output associated with "checking whether make sets $(MAKE)..." looked like a problem that I needed to correct somehow (in addition to the problems of getting the configure script to find headers and/or binary libraries). I don't recall how I stumbled upon the idea that letting my Borland make answer the configure script's question would solve the problem. Perhaps I just didn't have my gnu make in any of my PATH directories at some point. Anyway, when my Borland make was answering the configure script's question, the answer was simply a "yes" with no error messages. However, other tests showed that Borland make was not up to the task of building the library. So it seemed quite clear to me that I needed to comment out my gnu make when I wanted to run configure and then restore my gnu make when I wanted to run make. It is my guess that this situation has probably resulted in a lot of needless modification of Makefiles by me. So the point of this message is that the quoted output above regarding "checking whether make sets $(MAKE)" can be extremely misleading, especially to a newbie. If the configure script eventually comes up with the answer "no" (as above), it seems very likely that there is no problem here that requires "operator" intervention and/or adjustment in that regard, regardless of the error messages produced in the interim. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com