- GiNaC-list - ginac.de

Re: [GiNaC-list] [patch] Document that shared libraries are not supported on some weird platforms
by Richard Haney 21 Jul '06

21 Jul '06

Sheplyakov Alexei wrote: > So I propose to document that shared libraries are not supported on > MinGW. What about this patch? > > Index: INSTALL > =================================================================== [...] > --- INSTALL 19 Oct 2005 20:54:13 -0000 1.54 > +++ INSTALL 20 Jul 2006 13:37:43 -0000 [...] > +To build ginsh modified version of GNU readline library is necessary. It > +is available at <http://gnuwin32.sourceforge.net/packages/readline.htm>. [...] There is one more thing about the proposed use of the modified readline library. Since it seems that the primary advantage of the modified readline library is that it might permit an "automatic" default linkage to legacy UNIX functions in libgw32c.a , there is also a need for "automatic" default include directories as well. Having to explicitly specify prototypes for legacy functions in libgw32c.a would seem to defeat or complicate the purpose of using libgw32c.a . I suppose one possibility would be to use cygwin headers as a last resort (included farthest down in the source code if their inclusion is needed) and to use cygwin include directories as default include directories to be searched _after_ the default MinGW gcc system include directories, but how would one specify that to gcc? All the methods I know for specifying include directories to gcc place those directories ahead of the standard gcc system directories in priority. So I suppose that in order for the modified readline and libgw32c.a to be effectively useful, gcc would need to be rebuilt with such default lower priority directories specified automatically, but then the default legacy header files would also need to be supplied with the MinGW gcc standard header files in the packaging of the MinGW gcc standard runtime libraries. There is also the question whether inclusion of such a legacy header for a function xyz could cause a conflict between the legacy and main system prototypes for another function uvw whose prototype is specified in that legacy header and also in a main system header. Moreover, macro definitions and the like used for prototypes in system header files are often extremely complex so that a "casual" programmer might be extremely intimidated in attempting to make any ad hoc debug adjustments as to specifying prototypes. (I remember once having to modify a MinGW gcc system header because a simple macro variable in it collided with a variable of the same name in a build package; but fortunately only a simple change in the variable name in the MinGW gcc system header was sufficient to solve the problem so that I didn't have to understand everything that the header file was doing and how it related to other parts of gcc and the runtime libraries. I think this event probably occurred when I was doing a build of CLN or GiNaC a few years ago.) Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 21 Jul '06

21 Jul '06

Sheplyakov Alexei wrote: > You should definitely read this: > http://www.catb.org/~esr/faqs/smart-questions.html > > and this: > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > WARNING! These pages *DO NOT HAVE ANYTHING TO DO* with GiNaC! > They try to give an idea how to ask questions the smart way. > > > I had to do several fresh starts of ginac from .tar.bz2 to find out > > a workable use of the patch. > As usual, > patch -p0 < where/the_patch/is Thanks for the information. I appreciate the helpful comments and information. But I didn't think I was being stupid or rude, and even though the references are likely to be helpful, I am taken aback by the seemingly implicit "prickly-pear" attitude of those articles, and moreover, I think that the advice misses the point that the world of ideas and systems tends to be quite a bit more complicated than what the author presumes. Contrary to what the author seems to believe, I do not think there is a universal, "true", "right", "one-size-fits-all" way to ask questions. Lots and lots of things in computer systems routinely seem to be "broken" and I don't think it is necessarily due to the fault of "Microsoft Windows" or the saving grace of UNIX/Linux systems design. For example, there seems to be no "html" target in GiNaC Makefiles in spite of what the documentation seems to indicate. It's not just GiNaC. It seems to be quite frequent that documentation is often out of sync with actual systems development. So I suppose "stupid" questions would be inevitable. I suppose I could write a book about what's "wrong" with modern computer systems. But that's not my purpose. What I'd like to do is to understand the design philosophy as to why certain legacy practices and legacy designs seem to be needed. So I try to frame my questions in a way that will solve the most problems most effectively rather than to interminably nitpick a million and one questions in protracted, excruciating detail. Design schemes and philosophies matter. (But I also agree that examples and pertinent detail matters.) The "right" level of abstraction matters. But abstraction is an extremely fluid commodity. There is a lot of arbitrariness to it. And it often has the danger of leading to factional ideologies, flame wars, religious wars, and so on. There are lots of unanswered questions I have about GiNaC and its build process. Here are a few of the seemingly more important ones: Why is it necessary to specify the installation root directory at the time of running configure? Why can't that be done _simply_ at the actual time of doing the installation? Why is it necessary to use libtool? Is libtool a "fixed", universal product? Or is it simply something that is tailored specifically to the particular build process, in this case GiNaC's. Why is it necessary to compile each library module twice? (I suppose the idea is that two different versions are needed for the two different potential forms of the library: "static" and "shared". Is this true?) If a .dll version is not possible, can all the excess machinations be eliminated by declaring "--disable-shared" on the configure command line? Shouldn't a comment to this effect be put in the installation documentation so that mingw-users don't needlessly go through the excess machinations in the hopes of getting a .dll? There are probably other important questions that ought to be asked here, but the above are the more salient ones that come to mind. Sheplyakov Alexei wrote: > ./configure && make && make check && make install > > works just fine. If you happen to know a standard, "legacy"(?) configuration of your system that GiNaC build is happy with, I would expect your results. But when systems have a horrendous variety of degrees of freedom for creative, alternative designs, it is amazing the build process works at all. In any case, I would think it important to design the general build process to be both robust and flexible. Maybe this is not the right place to ask this question, but it does seem to matter here the most (grep is such a common tool that I doubt if there is a specific, preferred forum for this): I have not been able to get (cygwin or any other) grep to do a routine, "recursive" sweep through _all_ subdirectories. I have only been able to get sweeps at only fixed depths by using, for example, "./*/*/*" for the filename specification. Can anyone explain how to get a complete recursive sweep through all subdirectories with grep? The documentation seems to be silent on precisely what's needed here. Examples would help.

3 3

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 20 Jul '06

20 Jul '06

Or: Why GiNaC builds have not been straightforward It turns out that when the configure script tests for the existence of a usable readline function, it specifies -lreadline but not -ltermcap or the "curses" library, but modules in the readline static library apparently call functions that are not resolved by the linker. Those references are resolvable with the termcap library. (Readline installation documentation seems to say that the curses library can be used as an alternative to the termcap library.) A simple test program links quite well when both -readline and -ltermcap are properly specified. And by extracting the three object modules in libtermcap.a and inserting them in libreadine.a and by using this expanded libreadline.a, I was able to get the "make", "make check", and "make install" procedures to proceed without any need for modification of Makefiles; I did specify "--prefix=..." on the configure command line. (However, I did have to restart "make" because of errors due to timing out of subprocesses when the computer was put into hibernation; but there appears to be no deleterious effect as a result, and I had to copy my modified ginsh/ginsh_parser.cc from a previous build and either Sheplyakov's patched or my patched check/timer.h and check/timer.cpp as well as ginac/indexed.cpp with the assertion at line 701 commented out, and also Sheplyakov's patched "check/exam_archive.cpp".) Note that there seems to be no problem with unsatisfied "termcap" references when using the libreadline.5.dll and libhistory.5.dll that's created in the readline build, but of course, the configure script looks for libreadline.a, not libreadline.5.dll . One must manually modify ginsh/Makefile in order to use the .dll . So it would seem that the configure script should be modified to insert a -ltermcap or -lcurses (if that's the right name) -- or both (?) -- in the linker command line to test for readline, depending on what the script has found by prior tests -- or simply leave it a -lreadline only if neither of these extra libraries is found. If the unsatisfied references would never be needed for program flow, perhaps an option could be added to the linker command line to allow unresolved references (if there is such an option), or perhaps both -ltermcap and -lcurses could be specified along with an option to simply allow multiply-defined symbols and thus perhaps avoid any logic/decision-making fuss over which library should be used. These are just suggestions as to possibilities; I'm not familiar with the details here. Surprisingly, the unmodified ginsh/Makefile does put both -lreadline and -ltermcap on the linker command line to build ginsh. So it seems that -ltermcap was probably just inadvertently omitted in the configure script to test for the readline function. And incidentally, this supposed need for termcap seems to be counter to a comment and patch by Sheplyakov Alexei to the effect that termcap is being phased out; the details of this I'm not familiar with. Also, I used none other of Sheplyakov's and my patched files in GiNaC for this test run than those I specifically mentioned above as needing to be copied from a previous build. As for design of the configure script, it seems best that it should set the readline macros in config.h based on the headers found, regardless of whether a usable readline function is found. That would tend to simplify any debugging and manual adjustments needed when such a usable readline function is not found. But of course this would depend on the likelihood of various problematical states/scenarios when a usable readline function is not found. Incidentally, quite a bit of manual intervention, especially Makefile modification, was needed in building the readline/history libraries. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Python wrapper for a GiNaC derived library
by Vladimir Kisil 20 Jul '06

20 Jul '06

Dear All, Recently Daniel Seidel produced a Python wrapper for my "cycle" library announced here on Wed Dec 28 11:16:33 CET 2005. The wrapper is based on the pyGiNaC (http://sourceforge.net/projects/pyginac/) and is an example how a derived GiNaC libraries may be used in the interactive mode. The wrapper can be found here: http://www.maths.leeds.ac.uk/~kisilv/pycycle.html If you are curious what cycles are, then an easy-reading (I hope ;-) overview is here (http://arxiv.org/abs/math.GM/0607387) Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 1

well, here's the latest story on recursive grep
by Richard Haney 19 Jul '06

19 Jul '06

Effective recursive search with grep seems to be an important skill when trying to debug CLN and GiNaC. I tried a bit more searching on the Internet and tried a few more combinations with my existing versions of grep. Many of the alternative work-arounds posted on the Internet do not work very well. But I finally found a usage scheme that seems to work fairly well for recursive grep. I have four versions of grep on my computer and only cygwin grep seems to work reasonably well, provided one __guesses__ at the right combination of arguments. Here's what I've learned -- so you won't have to do such a horrendous amount of guessing. Here's a generic example of the usage of cygwin grep that works: grep -r --include="*.cc" --include="*.cpp" "Illegal number syntax" * Here's the command & output in a cygwin bash shell in working directory /cygdrive/c/gnu/cln-1.1.11/src: $ grep -r --include="*.cc" --include="*.cpp" "Illegal number syntax" * base/input/cl_read_err_bad.cc: fprint(std::cerr, "Illegal number syntax: \""); base/input/cl_read_err_bad.cc--debug.cpp: fprint(std::cerr, "Illegal numbe r syntax: \""); base/input/cl_read_err_bad.cc--original_now_in_effect.cpp: fprint(std::cerr , "Illegal number syntax: \""); (Note that I labeled backup copies with a .cpp extension because "CLN make" in this area sweeps up any existing file with extension .cc for inclusion in the library.) Using the option "--directories=recurse" in place of "-r" produces the same output. But note that while "grep -r "Illegal number syntax" *" searches _all_ files in the hierarchy and produces the output: base/input/cl_read_err_bad.cc: fprint(std::cerr, "Illegal number syntax: \""); base/input/cl_read_err_bad.cc--debug.cpp: fprint(std::cerr, "Illegal numbe r syntax: \""); base/input/cl_read_err_bad.cc--original_now_in_effect.cpp: fprint(std::cerr , "Illegal number syntax: \""); Binary file cl_read_err_bad.o matches Binary file cl_read_err_bad.o--comment out for debugging.oxx matches , the more specific command "grep -r "Illegal number syntax" *.cc" fails to produce the desired output, but instead we get: grep: *.cc: No such file or directory And, therefore to be expected, "grep -r "Illegal number syntax" *.cc *.cpp" fails in the same way: grep: *.cc: No such file or directory grep: *.cpp: No such file or directory Of my four versions of grep, only cygwin grep has the "--include=..." option. MinGW's msys grep does not have that option, and moreover, MinGW's msys grep has the same problem that cygwin grep has with the similar command: "c:/msys/1.0.8/bin/grep.exe" -r "Illegal number syntax" *.cc Version information: Executing the cygwin grep command "grep -V" produces the output "grep (GNU grep) 2.5" along with (gnu) copyright and (non-) warranty information. This grep was packaged in a cygwin setup.exe file that yielded an intermediate-expansion file (among many) with name "release\grep\grep-2.5-1.tar.bz2" along with a parallel intermediate-expansion file of "release\cygwin\cygwin-1.3.20-1.tar.bz2". Happy debugging! Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: ginac parsing from string issue (hopefully nailed!)
by Richard B. Kreckel 18 Jul '06

18 Jul '06

Francesco Biscani wrote: >I hope this can somehow be useful. I don't think I should open a bug against >gcc, since apparently in gcc-4.1.2pre the problem seems to be solved. > > Since things seem to point to aliasing problems in the bison-generated files, I became suspicious to my previous statement about gcc-4.1.2pre fixing the problem. Turns out, that statement was wrong. Gcc4.1.2pre is the current compiler in Debian/testing. Using that compiler and a fresh GiNaC 1.4 from CVS with one of the containter patches, I've just built a library where parsing is still broken. It appears like the GiNaC library in Debian/testing was compiled with an older compiler and not rebuilt since the compiler was upgraded, since there, parsing works as expected. Sorry -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 18 Jul '06

18 Jul '06

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

3 2

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 15 Jul '06

15 Jul '06

Here is another error, this time dealing with archiving, along with some additional, important, but non-critical issues. In response to "Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701", Chris Dams wrote: > I would say that you can quite safely just delete this assertion. Thanks for the post. I commented out the assertion at line 701 in indexed.cpp and rebuilt the library and ran "make checks". Here are the relevant parts of the relevant output files: output from the "make check-TESTS" part of "make check" output: <begin quote> [...] examining miscellaneous other things........ passed Error: something went wrong. (one failure) please check exams.out against exams.ref for more details. happy debugging! ./exams.ref exams.out differ: char 707, line 30 FAIL: run_exams [...] ====================================== 1 of 3 tests failed Please report to <ginac-list(a)ginac.de> ====================================== <end quote> relevant part of "exams.out" (from line 29 to end): <begin quote> ----------archiving system: archiving/unarchiving 42*y^sin(Catalan*y)*ONE*eps.(1/2*y).0.(FAIL)*x+(2.4275000000000002132)*eps~y~*0+(gamma~mu*gamma.mu)*x.(1+2*y)~(-mu)*(I*f.x.y.2+d.x.y.2)*T.x+delta.(delta.x.($7)*[[-1,0,0],[0,Euler,0],[0,0,atan(y^(-1)*x==-15/17*I)]])~(ONE*{x,-11*y,(acos(6-10*I))+(-(26/3725-48/3725*I)*sqrt(65+120*I))*(-3+5*I+x)+((17364/13875625-652/13875625*I)*sqrt(65+120*I))*(-3+5*I+x)^2+Order((-3+5*I+x)^3)}*g~2~(log(cos((128.0)*y^(-1)*x^(-1)))))+((abs(y))+(D[0](abs)(y))*(-y+x)+(1/2*D[0,0](abs)(y))*(-y+x)^2+(1/6*D[0,0,0](abs)(y))*(-y+x)^3+Order((-y+x)^4)) erroneously returned 42*y^sin(Catalan*y)*ONE*eps.(1/2*y).0.(FAIL)*x ----------structure template: (no output) ----------hash maps: (no output) ----------miscellaneous other things: (no output) <end quote> Could it be that the failure here is due to GiNaC's use of CLN's io functions and specifically is a result of a bug indicated in CLN's "test_I_io" failure as described in my previous post "[GiNaC-list] Results of GiNaC (& CLN) builds" at http://www.ginac.de/pipermail/ginac-list/2006-July/000857.html ? Additional issues: 1. Note that "cd .libs && rm -f libginac.la && ln -s ../libginac.la libginac.la" does not result in a new link file when rebuilding the library. (Output: "ln: `libginac.la': File exists".) I had to manually delete the link file (using Windows Explorer), whose full name is "libginac.la.lnk" and which seems to be the same thing as a "Windows shortcut". Only execution of "dir lib*" in Windows' "command prompt" shell reveals the complete name; "ls lib*" in cygwin bash only reveals the name "libginac.la" with an arrow ("->") to the referenced file. Nor does Windows Explorer reveal the full name even though I have "display filename extensions" turned on. (This comment applies similarly to the symbolic link "libcln.la.lnk" in the CLN build.) 2. The Makefile for building libginac.a does not seem to have the correct dependency information for the dependency of libginac.a on "indexed.cpp". I had to resort to manually deleting all known occurrences of "indexed.o", "indexed.lo", "indexed.Plo", "libginac.a", "libginac.la", "libginac.la.lnk", and "libginac.lai" in order to get the new version of indexed.cpp implemented in "libginac.a". (Conceivably, this may have something to do with "rm -f libginac.la" not being effective, as described in note 1 above. On a seemingly related note, it also seems that the Makefiles are confused about whether executables have an .exe extention. For example, the "clean" target in the "cln-1.1.11\tests" Makefile has command a line "$(RM) *.s *.o *.a exam tests main a.out core"; however, the Makefile in "ginac-1.3.4\ginsh" _does_ seem to account for the .exe extension in target "clean-binPROGRAMS". It has often seemed though that executables get automatically remade (in CLN and/or GiNaC) even though nothing has changed when rerunning make. I surmise that this may be due to incorrect specification of dependencies as to the .exe extensions. 3. There is some doubt in my mind whether symbolic links in cygwin bash work properly. I seem to recall trying to use a symbolic link a few years ago and found that I had to resort to simply copying the target file to replace the link. But I have not played with symbolic links in "standard" unix, so I don't know whether I was simply trying to use them incorrectly. 4. Now that a satisfactory build of libginac.a seems to be within view, I'd like to get a "shared" (.dll) version of both "libcln.a" and "libginac.a", but even though I think I am following directions for getting shared libraries, I don't seem to be getting them. A typical make output (for both CLN and GiNaC) that may have something to do with this is "libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries". Note that "cygwin" is only relevant by virtue of my using cygwin bash (& cygwin "sed", "ln", "mkdir', "rm", and perhaps some other minor tools that have escaped my attention). All of my essential build tools (except sed, etc.) -- i.e., gcc 3.4.2 and associated tools and runtime libraries -- are "mingw" tools or what is supplied with the CLN/GiNaC packages. The "mingw" tools bin appears earlier in PATH than does the cygwin bin. I surmise that, except where I specify otherwise more specifically, all of the runtime library paths are determined by gcc (or g++) relative to the location of the gcc/g++ bin. 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 P.S.: Thanks to Sheplyakov Alexei for his posts. I have looked at them and will look at them some more, but they are not in a form that I can readily make use of. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: ginac parsing from string issue (hopefully nailed!)
by Francesco Biscani 13 Jul '06

13 Jul '06

On Tuesday 11 July 2006 20:36, you wrote: > Please have a look at the ginac-list mailing list archives: The problem > has been traced to be in an interaction with the bison-generated file > with gcc 4.1.x. Hi Richy, I've followed the list's suggestion but unfortunately upgrading from bison-2.2 to bison-2.3 (and recompiling gcc+cln+ginac) did not solve the issue for me. However, one post in the list mentioned that turning off optimizations made the issue disappear. So I made a bisect search for the faulty gcc optimization starting from -O1 (where the problem was not present) to -O2, recompiling ginac each time. According to this, the optimization that causes the problem is "-fstrict-aliasing". Then I recompiled ginac with -O1 plus all the additional optimizations of -O2 (according to gcc man page) _excluding_ "-fstrict-aliasing". Now the test program runs properly :) I hope this can somehow be useful. I don't think I should open a bug against gcc, since apparently in gcc-4.1.2pre the problem seems to be solved. Suggestions are welcome... Thanks for all the help guys, now I can go back to coding :) Regards, Francesco -- Dr. Francesco Biscani Dipartimento di Astronomia Università di Padova biscani(a)pd.astro.it

4 6

Three "make check-TESTS" failures under Windows XP (with mingw tools)
by Richard Haney 12 Jul '06

12 Jul '06

It occurs to me that a more specific title is especially important since there seems to be no keyword search capability for the archives. With this post the above title should provide additional, more-specific linkage to the following post under the title "[GiNaC-list] Results of GiNaC (& CLN) builds": http://www.ginac.de/pipermail/ginac-list/2006-July/000857.html Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0