[GiNaC-list] Results of GiNaC (& CLN) builds

[Richard Haney]

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