- CLN-list - ginac.de

Additional Missing ".exe"s in Makefile(.in)s... [Was: CLN vs weird mixture of Cygwin and MinGW [Was: ...]]
by Richard Haney 06 Sep '06

06 Sep '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > > [...] error in regard to the > > missing .exe extensions for executable targets in Makefiles. > > Autoconf does its job right, but CLN's tests/Makefile.in do not care > about $(EXEEXT). Attached patch should fix this. [...] > > Index: cln-1.1.13/tests/Makefile.in > =================================================================== > --- cln-1.1.13.orig/tests/Makefile.in 2006-08-13 14:21:23.000000000 > +0400 > +++ cln-1.1.13/tests/Makefile.in 2006-08-13 14:56:16.000000000 +0400 [...] Thanks. I would think the patch should also extend to the executables in target "clean" something as follows clean : force - $(RM) *.s *.o *.a exam tests main a.out core + $(RM) *.s *.o *.a exam$(EXEEXT) tests$(EXEEXT) main a.out core $(RM) -r .libs _libs I'm not sure about "main" or what its purpose is; no executable "main.exe" (nor even a file "main") seems to be created in my build even though there is a module "main.cc". Module "main.cc" looks like it is designed for experimental testing of type conversion and/or output, perhaps for debugging purposes. Also, I would think a similar patch for examples/Makefile.in and benchmarks/Makefile.in would also be appropriate since the associated Makefiles are used to build executables in the associated directories. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

recent Makefile change
by Ralf Wildenhues 06 Sep '06

06 Sep '06

Hello, Just curious: Is there any technical reason for this recent change in the CVS version of CLN, or is that just for (non)readability? * Makefile.in: Convert from $(VAR) to ${VAR} syntax. * benchmarks/Makefile.in: Likewise. [...] Cheers, Ralf

2 3

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 30 Aug '06

30 Aug '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: [...] > On Sun, Aug 13, 2006 at 07:42:59PM -0700, Richard Haney wrote: > > [...] [...] > On my Duron 800 with 512Mb RAM (running Debian GNU/Linux sid) running > GiNaC configure script takes about 1 minute. On ReactOS it is indeed > somewhat slower, but it is not *that* slow. Thanks, that's good to know. > > uname -s = CYGWIN_NT-5.1 > > You are trying to make win32 libraries with a mix of Cygwin and MinGW > tools. While it is certainly possible build win32 libraries/binaries > with such a setup, it is a little bit tricky, [...] Among the executables (".exe"s as well as scripts) in /bin and in /cygdrive/c/Dev-Cpp/bin , the only ones that could clash are the two versions of rm.exe that I mentioned. The /usr/bin and /usr/local/bin directories are not used. It seems that for a build only the MinGW tools (in /cygdrive/c/Dev-Cpp/bin ) are concerned with interpreting the contents of files (apart from whatever goes on in the interpretation of link files). I chose to re-order those directories in PATH because of the conflict with versions of rm.exe , but I could have done instead an override of, say, RM="C:/cygwin/bin/rm.exe" on the configure command line. > [...] so I suggest you to use > MSYS. > BTW, running shell scripts with MSYS is *much* faster. Thanks, that's good to know. I've been using cygwin because 1) (originally) msys seemed to have a bug in regard to setting the size defaults for the script window. 2) (later) I became used to using cygwin and was concerned that my experience (implicit knowledge) about cygwin would not carry over very easily or entirely to msys -- especially in regard pathnames conventions. 3) (most recently in regard to grep) I have subsequently learned that cygwin seems to have distinctly better tools -- at least in regard to grep -- and a larger variety of tools, whereas msys _seems_ to be a bit limited. So, I'm wondering about what bugs/limitations may be lurking in msys, which I have not tried much. > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc So why not i686 in place of i586 , since configure seems to think my computer is a i686 (whatever that is, precisely)? Also, the "msvc" seems to stand for "Microsoft Visual C/C++", or does that refer to a Microsoft DLL with the same string "msvc" in its name? Are there only a limited list of possible values for --build=... and --host=... ? Where are they defined (and/or described in human-readable form)? > > 2) make sure that directories with MinGW tools listed first in your > $PATH, > which is not the case with your setup: See comment above in regard to possible "clashes" between the directories, including "rm.exe". > > Hopefully, the config.log file will also help in determining why > > the default value for the Makefile INSTALL variable > There is no such a default. The value of this variable is determined > by the configure script, which is basically searches for required > program in your $PATH. By "default value" I meant the value that is set in the Makefiles in the absence of an override set on the configure command line. > > causes a crash in the doc directory for "make install". > I think it is either Cygwin bug or just your setup is horribly > broken. Yes, this is very much a puzzle still. It seems to me that a few years ago I tried copying a failing command line from make output and inserting that line directly in the cygwin bash shell and then the command worked as intended, and it seems to me that this "experiment" was concerned with the process of installing from the doc directory, but all of that was some time ago when I did that and I don't recall the details. Quite possibly it could have been the very same command that failed in this most recent case. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 25 Aug '06

25 Aug '06

Hi Alexei and others who may wish to comment, --- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc I guess I really need to ask a question explicitly, rather than simply leaving the question implicit from my two messages ( http://www.cebix.net/pipermail/cln-list/2006-August/000228.html and http://www.cebix.net/pipermail/cln-list/2006-August/000229.html ). It _seems_ to me, based on my (admittedly limited) knowledge and on "grep"ing directories and exploring files as described in my first of the two messages, that > --build=i586-mingw32msvc --host=i586-mingw32msvc is incorrect because: (1) my processor is a Celeron processor, which seems to mean that the first part of the system type should be "i686" and not "i586" (as explained in my first of the two messages), and (2) because there is no meaningful occurrence of the string "msvc" in "C:/gnu/cln-1.1.13" or in "C:/gnu/cln-1.1.13/autoconf", which fact _seems_ to suggest that the second part of the system type should definitely not be the "mingw32msvc" that was suggested above. Moreover, $ uname --help [...] -s, --kernel-name print the kernel name [...] seems to suggest that "uname -s = CYGWIN_NT-5.1" in the config.log gives the best available idea of what should be considered the "kernel". So it _seems_ (to me, based on my admittedly limited knowledge) that the result from the configure output checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin is the best possible information. I don't really know what the build process does with this information. But it seems to me that the fact that gcc and its associated tools (as, ld, ... ) are MinGW tools (which, as I understand it, means that they and their output, where applicable, link directly to the Windows system DLLs rather than to cygwin1.dll) should be of no real concern to the build process. So this suggests that there should be no need for information such as "mingw32" in the build process (specifically the scripts). Moreover, by comparing script names and other executable names in the two directories "C:/cygwin/bin" (the bin for cygwin executables) and "C:/Dev-Cpp/bin" (the bin for MinGW tools), the only potential conflict I found was the existence of two different versions of "rm.exe". So it seems that putting "C:/cygwin/bin" first in PATH was an appropriate arrangement in order for configure to use the cygwin version (of rm.exe), which deletes symlinks properly. (The alternative arrangement would have led to using RM=... explicitly on the configure command line or simply removing or renaming the rm.exe in "C:/Dev-Cpp/bin".) So my questions are these: Are my best guesses as described here mistaken? And if so, where are they mistaken? If using > --build=i586-mingw32msvc --host=i586-mingw32msvc on the configure command line really is a better practice, why? Also, does the description "weird mixture of Cygwin and MinGW" merely reflect that the author is simply unfamiliar with this use of Cygwin and MinGW? Or is there some other matter in this regard that I should consider? BTW, I think I have seen the use of Cygwin and MinGW tools in this way described, perhaps even by MinGW FAQ files, as something that seemed to be considered a "normal" option for development and porting. The alternative to cygwin bash (and its associated unix-style utilities), namely MinGW's msys system (including msys bash), originally seems to have been provided, not because of any real technical need or usefulness, but rather for the sake of completeness and project independence from cygwin. For those interested, note that I have described my reasons for using cygwin rather than msys in my message http://www.cebix.net/pipermail/cln-list/2006-August/000221.html . Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 22 Aug '06

22 Aug '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc I thought about this some more and also perused apparent script-file definitions since my last post on this subject. It appears that "uname -s = CYGWIN_NT-5.1" is _supposed_ to be the "kernel name". That sounds like some variant of "cygwin" would be the appropriate value, and not some variant of "mingw32". (But I can see why some variant of "msvc" _might_ be thought to be appropriate as part of the identification; however, no variant of "msvc" seems to be valid, as far as I can tell.) So it seems to me that the configure script is coming up with exactly the right value "i686-pc-cygwin" since my processor is a Celeron processor. But I suppose the answer may hinge upon what is considered a "kernel" for practical purposes. So I guess what's puzzling me is why there should be any problem with "Cygwin+MinGW" in the way that I'm doing it. I seem to recall that I read somewhere where even the Cygwin gcc project eventually came over to using MinGW gcc as the standard compiler for Cygwin. The only major difference was that the new gcc no longer used "cygwin1.dll" to satisfy links, but rather started using the Microsoft Windows system DLLs directly. I don't see how that should be of interest to the configure script; that fact seems to be something that would ordinarily be "hidden" from the configure script. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 22 Aug '06

22 Aug '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc I did a grep first on "i586-mingw32msvc" and found nothing and then on "i586". The following code in config.guess seems particularly interesting: case `/bin/uname -X | grep "^Machine"` in *486*) UNAME_MACHINE=i486 ;; *Pentium) UNAME_MACHINE=i586 ;; *Pent*|*Celeron) UNAME_MACHINE=i686 ;; esac This seems to say that a Celeron processor should be identified as an "i686" rather than a "i586"; and that is exactly what the configure script determined, as shown in the config.log file. My processor is a "Inspiron 2650 Notebook: Intel® Celeron® processor, 1.5GHz-M", according to the sale specification provided by Dell. So, assuming that the script(s) must ordinarily piece together the identification in place of the "--build=..." info, it would seem that the first part of "--build=..." value, if needed, should be "i686". But I also did a grep on "mingw32msvc" and found nothing and then on (case-insensitive) "msvc" and found _only_ some comments to the effect "# FIXME: the MSVC++ port hasn't been tested in a loooong time". (BTW, all "grep"s were case-insensitive.) Thus, it appears that the configure script, without the override you suggest, correctly determines the type of processor I have, and the "mingw32msvc" certainly seems erroneous since not even a meaningful "msvc" can be found. I also did a grep on "mingw32" and found a line "config.guess:776: echo ${UNAME_MACHINE}-pc-mingw32", which seems to suggest, with the earlier information above, that "i686-pc-mingw32" would be an appropriate value for "--build=..." and "--host=...". However, it seems that it should be _very_ easy for the configure script to figure out that the compiler I'm using is a MinGW gcc compiler. So I would think that the configure script would be able to determine on its own that the appropriate value is "i686-pc-mingw32", without my having to provide an override. But evidently the cln configure script came up with "ac_cv_build=i686-pc-cygwin" and "ac_cv_host=i686-pc-cygwin". Of course, I am largely guessing about things here based on what I found. I also examined the ginac-1.3.5 files as well, without having run ./configure, and the situation seems to be the same there as far as the script files are concerned. So my questions are these: Would "--build=i686-pc-mingw32 --host=i686-pc-mingw32" be the appropriate override? And moreover, shouldn't this need for an override be considered a bug in the configuration scripts; shouldn't the scripts be able to determine this value without the override since I'm essentially telling configure to use my MinGW gcc? Note the "CC=C:/Dev-Cpp/bin/gcc" and "CXX=C:/Dev-Cpp/bin/g++" on the configure command line. And note also that the config.log file has this line (which is somewhat puzzling since, in particular, I don't know of any command "../gcc/configure"): Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Patch to convert cl_I to and from a byte stream
by Igor Khavkine 17 Aug '06

17 Aug '06

Hello, Recently, I've had to use CLN in conjunction with GiNaC. Unfortunately, I've found that it's hard to pass numbers from applications that use CLN to applications that use other libraries, such as GMP or Python. The most efficient method I've found is through a base-16 or base-32 string representation. I think the conversion would be much simpler if CLN could export its numbers as byte streams (basically in base-256), say little endian and signed. Conversion through this intermediate format would then simply be a matter of memory copying together with some fiddling that each library has to do to construct its internal number representation. I've written a few simple routines that allow the conversion based on the conversion to and from a digit sequence (DS) that CLN already supports (although does not export). I'm attaching a patch with these routines. Please consider adding it to the next CLN release. As is, the patch probably needs some work to seamlessly fit into the library. For instance, I'm sure some of the code could be shortened if some of the internal CLN macros for working with different endian storage schemes were used. For another thing, I'm not sure where to place the prototypes of these routines to add them to the library's exported interface. Thanks. Igor

2 4

Oddity in CLN documentation? (Was: [GiNaC-list] Possible size issue in test in numeric.cpp)
by Pierangelo Masarati 17 Aug '06

17 Aug '06

CLN documentation in Section 3.1 states that <snip> Small integers (typically in the range -2^29...2^29-1, </snip> while in Section 3.4 it states that <snip> The conversion from `int' works only if the argument is < 2^29 and > -2^29. </snip> This is not necessarily contradictory, but it sounds a bit odd. Why would -2^29 be legal for small integers if no conversion can occur for that value? p. Dr. Pierangelo Masarati | voice: +39 02 2399 8309 Dip. Ing. Aerospaziale | fax: +39 02 2399 8334 Politecnico di Milano | mailto:pierangelo.masarati@polimi.it via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

1 0

Re: [GiNaC-list] Possible size issue in test in numeric.cpp
by Pierangelo Masarati 17 Aug '06

17 Aug '06

[cross-posting for clarification] Pierangelo Masarati writes: > Richard B. Kreckel writes: > > [snip] > > Also, CLN's documentation states that |i| < 2^29, which means that the > test in GiNaC for integers could be broken as well, as it does > > i >= -(1L << (cl_value_len-1)) > > which allows |i| == 2^29 when i is -2^29 (assuming cl_value_len == 30). Actually, CLN documentation in Section 3.1 states that <snip> Small integers (typically in the range -2^29...2^29-1, </snip> while in Section 3.4 it states that <snip> The conversion from `int' works only if the argument is < 2^29 and > -2^29. </snip> This is not necessarily contradictory, but it sounds a bit odd. Why would -2^29 be legal if no conversion occurs for that value? I'll post this remark to the cln-list as well. p. Dr. Pierangelo Masarati | voice: +39 02 2399 8309 Dip. Ing. Aerospaziale | fax: +39 02 2399 8334 Politecnico di Milano | mailto:pierangelo.masarati@polimi.it via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

1 0

Re: "offensive phrase"
by Richard Haney 16 Aug '06

16 Aug '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > On Sun, Aug 13, 2006 at 07:42:59PM -0700, Richard Haney wrote: [...] > > and could possibility be misconstrued as to > > being of any general significance by sufficiently > > ignorant people. > ... but instead of writing such an offensive phrase you > could have modified your PATH before running configure > to not contain that directory. Sorry, no offense was intended. I can only guess that perhaps the phrase "sufficiently ignorant people" may have seemed offensive because I have sometimes, but not frequently, heard people, when speaking of ignorance, to speak with much distain and arrogance as if there is shame in ignorance. And in so doing they show personal and/or social and/or cultural attitudes/values apart from any fact of ignorance itself. But it seems to me that there should be no shame in _mere_ ignorance. It is a fact is that everyone is ignorant of a great, great many things, and it seems the totality of human knowledge is extremely miniscule compared to what is potentially knowable. Moreover, it also seems severely impossible for any human to even be knowledgeable about everything humanly known and humanly important (sometimes even in a rather limited context). There seems to be some "truth" to the idea one sometimes hears in a jocular context of someone "having just barely enough knowledge (about something) to be 'dangerous'". That is approximately the sense in which I intended the phrase "sufficiently ignorant people". I suppose encyclopedias could be written about the idea of ignorance (just as much has been written, especially by philosophers, about ideas of "knowledge"). And it seems there is probably a great, great deal of unwritten "knowledge" (or at least cultural and social attitudes and values) about ignorance. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0