[GiNaC-list] How output from the configure script can be quite
rfhaney at yahoo.com
Sat Jul 22 01:47:58 CEST 2006
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:
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
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
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.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the GiNaC-list