Building ginac has been a horrendous, labyrinthine exercise, and I finally have a successful build and "make check". It was not the "breeze" that Sheplyakov Alexei seems to think it is. Sheplyakov Alexei wrote:

I've attached two patches. [...]

Second one is for GiNaC 1.3 ("backport" from 1.4 branch) -- it contains *all* changes which make GiNaC compile on MinGW.

I created a fresh, alternate build hierarchy and ran patch.exe using Sheplyakov's "ginac_1.3_mingw32.diff". I had to do several fresh starts of ginac from .tar.bz2 to find out a workable use of the patch. I have no cygwin patch program, but the one I found is from my mingw "msys" basic file utilities "bin". However, it seems that this patch.exe does not know how to handle relative pathnames. It tried to modify the root directory's "Makefile.am" instead of "check/Makefile.am". I also found that modifying "configure.ac", "acinclude.m4", and "Makefile.am" with the patch resulted in a need apparently for autoconf and perl, and, And moreover, the patch for "ginsh/ginsh_parser.yy" resulted in a need for yacc. And among other concerns, I did not have ready access to the Internet at the time to search for these extra resources, and I was reluctant to go rummaging around on my disc drive for old versions. Since it appears that the patches for the root directory's "configure.ac" and "acinclude.m4" are only concerned with extra checking for resources for ginsh, I figured I could safely skip those patches because I was already able to build "ginsh.exe" in a previous attempt. But it looked like the patch for "check/Makefile.am" might be crucial; so I used the context information in that patch to manually modify "check/Makefile" rather than to patch "check/Makefile.am". Also, the patch for "ginsh/ginsh_parser.yy" seemed to be concerned only with the issues I had dealt with when I earlier modified "ginsh/ginsh_parser.cc". So I used my earlier-modified "ginsh/ginsh_parser.cc" rather than to patch and use "ginsh/ginsh_parser.yy". So that eliminated any need for yacc. There are a few other facts that might be useful to note here. This time, in an effort to discover the "breezy" approach to building ginac as Sheplyakov suggests, I did not bother to do the "commenting out" of my make.exe for the run of configure. Evidently, configure adjusted the Makefiles slightly and accordingly from what they would have been otherwise, and no problem seemed to arise from this fact. I discovered that symbolic links (to readline headers) in a "readline" subdirectory of my standard system "include" directory was sufficient for configure to find the headers, and I discovered that even with this "readline" "commented out", configure/gcc/g++ was able to find the headers with environment variable CPLUS_INCLUDE_PATH set in my .bash_profile, in this case, as follows: export CPLUS_INCLUDE_PATH=C:/gnu/readline-5.1/gcc342/include (At the moment I am partial to the idea of keeping installations as part of the original build hierarchy by, for example, adding a subdirectory "gcc342" as the root of an installation, based in this case, on gcc 3.4.2. And so, for example, I would like to be able to tell configure by use of an environment variable where to find my relevant libraries, rather than to "dump" all my libraries into a common directory.) But I could not get configure/gcc/g++ to find my libraries by use of export LIBRARY_PATH=".:/cygdrive/c/gnu/cln-1.1.11/gcc342/lib:/cygdrive/c/gnu/readline-5.1/gcc342/shlib:/cygdrive/c/gnu/readline-5.1/gcc342/lib:" in accordance with the gcc manual. This is supposed to be a colon-delimited list of directories much like PATH; so use of "C:" to start a pathname (as gcc seems to prefer) would conflict with the use of the colon as delimiter. I tried all sorts of combinations of quotes in order to use "C:", but nothing seems to work here. So configure steadfastly "refused" to find my readline binary libraries -- even when I "dumped" all the readline headers and binaries into my main development hierarchy. So I had to manually modify ginsh/Makefile as I had done before to point to my "libreadline.5.dll". (I suppose I may not have restarted cygwin bash; cygwin bash seems to "remember" where files are found (or not found), and restarting cygwin bash sometimes seems necessary to refresh its memory.) Moreover, even though configure found my readline headers, it refused to adjust config.h accordingly; I had to use my previously modified config.h here as well. I am also wondering about "manual" installation of CLN (& GiNaC). It seems that cln-config did not get copied to the "bin" directory in the installation hierarchy; so I copied it manually, using Windows Explorer "copy-and-paste" as I have done for some other installations; that seemed to satisfy configure. And it is a puzzle to me why configure looks for "cln-config"; when I modify Makefiles, simply listing -lcln (with appropriate "-L" options) or its full pathname seems sufficient; so why should "cln-config" be of any concern to configure? But I somehow get the impression that there my be important, mysterious things going on with a "make install" (and the build process in general) that may be escaping my attention. Can anyone provide some general comments on when it is safe to do a manual "copy-and-paste" installation? Incidentally, manually modifying files (such as cln-config or ginac-config) can trigger all sorts of frightful rebuilds when running make. Such manual modification is tempting in order to avoid the rather time-consuming and seemingly inflexible rerun of configure that the instructions suggest for changing the "--prefix=..." information. But the "--prefix=..." information resulting from configure seems to be peppered throughout the build hierarchy; so that idea of modifying each such relevant file (and perhaps restoring its time-stamp) seems horrendous. I am still a bit confused as to what in entirety it going on with installations, especially those that have been built using libtool; and I'm still also a bit confused as to what libtool does in its entirety. Does the build process really have to be so complicated and obscure? Those ginac Makefiles are really horrendous to try to trace through. As before, the relevant system specs are: OS: Windows XP 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 gdb: version 5.2.1 (from gdb-5.2.1-1.exe ) _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash (for environment variables & executing configure & make commands): GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.11 GiNaC: version 1.3.4 Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com