August 2006 - CLN-list

problems building on powerpc64
by Dmitry Khutornoy 05 Dec '07

05 Dec '07

Hello! I got problems with building CLN on PowerPC64. uname -a Linux blade1 2.6.5-7.252-pseries64 #1 SMP Tue Feb 14 11:11:04 UTC 2006 ppc64 ppc64 ppc64 GNU/Linux make ... In file included from base/cl_N.h:6, from base/cl_as_err.cc:7: ../include/cln/number.h: In constructor `cln::cl_number::cl_number()': ../include/cln/number.h:191: error: `cl_FN_tag' undeclared (first use this function) ../include/cln/number.h:191: error: (Each undeclared identifier is reported only once for each function it appears in.) And it seems i know why does it happen: <config.h> ... #ifndef __powerpc64__ #define __powerpc64__ 1 #endif ... <object.h> ... #if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__) #define cl_word_alignment 8 #endif ... // Definition of the tags. #if !defined(CL_WIDE_POINTERS) #if (cl_word_alignment == 2) #define cl_FN_tag 1 #define cl_SF_tag 3 // must satisfy the cl_immediate_p predicate! #endif #if (cl_word_alignment == 4) #define cl_FN_tag 1 #define cl_SF_tag 2 #endif #else // CL_WIDE_POINTERS // Single Floats are immediate as well. #define cl_FN_tag 1 #define cl_SF_tag 2 #define cl_FF_tag 3 #endif There is no branch defining tags for powerpc64 (cl_word_alignment==8) Please, tell me what values should i write in #define or explain what am i doing wrong. Thank you! -- Best regards, Dmitry mailto:khutornoy@gmail.com

3 5

How to cite cln
by Wilson Castro 28 Jul '07

28 Jul '07

Hello cln-developers and cln-listmoderator, I want to know how it is the correct form to cite cln. 1. first in a paper? 2. in a GNU-software for Linux that uses the library? best regards -- Ms. C. Wilson Castro Rojas Foundations of Informatics Group, Department of Informatics, University of Kaiserslautern, Germany, PO Box: 3049, Building: 34/423, Phone: ++49 631 205 2155, Fax: ++49 631 205 2156,

5 33

Anomaly when integer zero combined with extended float.
by Ray Buvel 09 Sep '06

09 Sep '06

I ran across an anomaly in CLN that occurs when an integer zero value is combined with an extended precision floating point number. Consider the following cl_R a,b,r; Now assign a cl_I variable whose value is zero to a, and a high precision cl_LF value to b. Then perform any of the following operations. r = a * b; r = b * a; r = a / b; In every case, the precision degrades to the default value. However, if the integer value in a is anything other than zero, the result has the precision of b. Since this only occurs for multiply and divide, I suspect it may be due to some shortcut that is taken when one of the operands is zero. The same anomaly occurs if the variables are declared cl_N and operand b is a high precision floating point complex number. The simplest way to demonstrate this behavior is to use the clnum Python module. The following session is on a 64-bit platform with version 1.1.9 of CLN. >>> from clnum import mpf >>> x=mpf(1,50) >>> x mpf('1.0',55) >>> 0*x # Results in default precision mpf('0.0',36) >>> 1*x # Preserves the precision mpf('1.0',55) Ray Buvel P.S. Is there another way to report anomalies other than posting to the list?

2 2

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