- CLN-list - ginac.de

Re: [CLN-list] [GiNaC-list] msvc support patch (Was: use of STL iterators in GiNaC)
by Michael Goffioul 21 Apr '09

21 Apr '09

On Sun, Apr 19, 2009 at 9:53 PM, Richard B. Kreckel <kreckel(a)ginac.de> wrote: > Hi! > > Michael Goffioul wrote: >>> >>> (How) Did you manage to compile CLN with msvc? >> >> Magic. >> >> VC++ per-se is quite (not fully) standard compliant. Most of the >> problems are in the autotool based build framework. With a bit >> of coding, you can make VC++ look like GCC. > > Interesting. Could you write up a summary of what you did and report it on > <cln-list(a)ginac.de>? This way, others will have a chance to pick up on your > work. CLN/GiNaC compilation with VC++ is part of the making of Windows package for octave. All compilation scripts and patches are available under SVN on octave-forge http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Wi… (run_compilation.sh and libs/) The main problem when compiling packages with VC++ is not the compiler itself, which is pretty C/C++ compliant, but the build toolchain. Most packages in the UNIX world use autoconf/automake/libtool toolchain and those tools do not support VC++ very well (at all). But you can work around that problem by using wrappers around VC++ compiler to make it look like GCC, by translating command flags. You can use such wrappers to build tools equivalent to gcc, g++, ar, ranlib... but based on VC++. You can also provide some missing headers like stdint.h, inttypes.h or unistd.h (you can find some on the web), to further ease porting packages. Once you have those tools, it becomes easier to compile packages using the normal "./configure && make" way, using the MSYS shell. But you still need to take care of some specific issues: 1) libtool: using some post-processing magic, it's possible to make libtool to support VC++ (through the gcc-like wrappers) 2) symbol export: VC++ does not export symbols automatically, so you need to take of it; either by using a .def file (some packages provide their own), or by using dllexport/dllimport qualifiers (again some packages support that as well), or by parsing yourself the object files to generate a .def file automatically (this works well especially for plain C code); of course, when you build a static library (which is what I do or CLN/GiNaC), you don't have to care about that 3) export of data: even with the tricks of point 2), you still need to decorate exported data with dllimport, as VC++ does not have the auto-import feature of MinGW; for packages that do not provide this decoration, you have to write your own patch. For the specific case of CLN, there were a couple of issues I also had to take care of: - struct/class, const/non-const: at some places, CLN foward declares objects as being "class", while there are actually "struct"; VC++ generates different mangled names for struct and class, so you end up with unresolved references. The same happen for const/non-const (forward declare as non-const, but define as const). - assembly code: here I cheated a little bit and used gcc to compile the .S file; this required some hacks in the Makefile - some namespace issues: apparently, declaring a function inside the body of another method, which is parted of the cln namespace, does not make VC++ to tag the declared function with the cln namespace; for instance in number.h, I had to move the "extern" statements of CL_DEFINE_LONG_CONSTRUCTOR out of the method bodies. Bye, Michael.

4 6

CLN repository, the fork, and all that
by Richard B. Kreckel 04 Feb '09

04 Feb '09

Hello, Here is some information about the immediate future. I've traded the CVS repository for a git repository. The CLN web page informs about how to obtain the current sources and how to build them. Actually, that is a clone of the CVS-to-git conversion done by Alexei Sheplyakov, who announced it as a fork on this list a while ago. Alexei has explained that he intends to continue to contribute to CLN. Technically, he will do so by sending requests to pull from his repository. After all, that is how git is designed to work. In this spirit, all his patches to make CLN less dependent from GCC are already in the current repository. Kudos to Alexei for making this possible. Everyone is invited to give the current version a test. Please report any problems you may find. Please send reports to this list. Better yet, send patches! ;-) My immediate plan is to prepare a release at around the time GCC-4.4 is released. Due to some minor header problems, CLN-1.2.2 won't compile on that new compiler version. Since Alexei's work made changes to the ABI, the new release will have to increment the soname version. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

modular polynomials
by Jens Vollinga 30 Sep '08

30 Sep '08

Hi, using cl_UP_MI I get very strange effects that look like problems with the memory management (the contents of one polynomial is suddenly vanishing while operating on another for example). So far, I figured out that having the leading coefficient set to zero via set_coeff() causes trouble even if I call finalize(). The manual is kind of sparse on that topic so I am not quite sure whether this is a bug or a feature. But even when I try to avoid that case, call finalize everywhere, and only do assignments (hope they are safe ...), then polynomials aside from the ones involved in the operations change. I will investigate this case further but it would be helpful to know whether the cl_UP_MI has problems/bugs? Regards, Jens

4 10

FYI: CLN fork
by Alexei Sheplyakov 27 Aug '08

27 Aug '08

Hello! CLN is a great library, but it has a number of problems. 1. CLN can be built only with GNU C++ compiler. Even worse -- some bits of CLN (in particular, include/cln/modules.h) work only with specific versions of GCC, so CLN can break at any moment (this actually happens with every new [major] release of GCC). 2. The code is a bit obfuscated. 3. The build scripts are extremely user- and hacker-hostile. Since CLN developers keep [silently] refusing patches addressing these issues, I've decided to fork CLN. The code can be obtained from git repository: git://ffmssmsc.jinr.ru:443/varg/cln.git To view the repository on-line point your browser to http://ffmssmsc.jinr.ru/~varg/git/gitweb.cgi?p=varg/cln.git Best regards, Alexei -- All science is either physics or stamp collecting.

2 1

floating point overflow
by David van der Spoel 03 Jun '08

03 Jun '08

Hi, I get the following message when trying to do a rather complex piece of code: terminate called after throwing an instance of 'cln::floating_point_overflow_exception' what(): floating point overflow. I am running on a Mac in 64/Intel bit mode as per the instructions in previous posts, with GMP. This is using cl_F with 100 decimals precision throughout. Any clue what causes this and how to prevent it? -- David van der Spoel, Ph.D., Professor of Biology Molec. Biophys. group, Dept. of Cell & Molec. Biol., Uppsala University. Box 596, 75124 Uppsala, Sweden. Phone: +46184714205. Fax: +4618511755. spoel(a)xray.bmc.uu.se spoel(a)gromacs.org http://folding.bmc.uu.se

2 1

CLN 1.2.2 released
by Richard B. Kreckel 07 Apr '08

07 Apr '08

Hi! CLN 1.2.2 has been released. This release re-establishes binary compatibility with CLN-1.2.0 and fixes the ARM build, both inadvertently broken in the previous release. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 7

Re: [CLN-list] CLN 1.2.1 -- silent ABI change?
by Richard B. Kreckel 05 Apr '08

05 Apr '08

Bruno Haible wrote: > Hi Richy, > >> Indeed: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473494>. > > This can be solved by rebuilding the Ginac package, no? Yes. >> Oh, no! Oh, no, no nooooo!!! This entire library versioning scheme sucks >> so big time. I've read all the docs and it didn't help because I missed >> that change. It is theoretical mumbo-jumbo unless one has an actual ABI >> testsuite and uses it on a regular basis. This is especially true for >> C++ libraries. > > Theoretical mumbo-jumbo? The docs say that a library maintainer has to > determine four things: > - Has the library source code has changed at all? I make diffs for > the entire source code between the previous and the current release. > - Have any interfaces have been added, removed, or changed? I make diffs > for the include/ directory between the previous and the current release. > - Have any interfaces have been added? Same. > - Have any interfaces have been removed? Same. Frankly, it hadn't occurred to me that anybody would diff the package against the previous release. (Maybe one could diff symbols using nm, or so.) Anyway, there are two more options for CLN-1.2.2: * Back out the patch. * Add a function that re-establishes binary compatibility but don't expose it in the public header file. Still pondering... -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 7

CLN 1.2.1 -- silent ABI change?
by Alexei Sheplyakov 03 Apr '08

03 Apr '08

Hi! I've tried to install (and use) CLN 1.2.1. My programs linked with CLN 1.2.0 stopped working due to undefined symbols: $ ginsh ginsh: symbol lookup error: /usr/local/lib/libginac-1.3.so.2: undefined symbol: _ZN3cln23cl_double_to_DF_pointerERKNS_11dfloatjanusE I think the SONAME should be changed to indicate incompatible changes. diff --git a/configure.ac b/configure.ac index 051223e..9188ad9 100644 --- a/configure.ac +++ b/configure.ac @@ -91,8 +91,8 @@ dnl * if any functions/classes have been added, increment CL_AGE, dnl * if backwards compatibility has been broken, set CL_AGE to 0. dnl $(CL_CURRENT):$(CL_REVISION):$(CL_AGE) results in dnl libcln.so.$(CL_CURRENT)-$(CL_AGE) -CL_CURRENT=5 -CL_REVISION=1 +CL_CURRENT=6 +CL_REVISION=0 CL_AGE=0 dnl make substitutions AC_SUBST(CL_CURRENT) Best regards, Alexei -- All science is either physics or stamp collecting.

2 3

const cl_LF operator- (const cl_LF& x, const cl_LF& y)
by zhaoxinjian 03 Apr '08

03 Apr '08

Hi, I find that the function ( const cl_LF operator- (const cl_LF& x, const cl_LF& y) ) in cl_LF.h and in cl_LF_2mimus.cc is different! In cl_LF.h: inline const cl_LF operator- (const cl_LF& x, const cl_LF& y) \ { \ return LF_LF_minus_LF(x,y); \ } In cl_LF_2mimus.cc : const cl_LF operator- (const cl_LF& x1, const cl_LF& x2) { GEN_LF_OP2(x1,x2,LF_LF_minus_LF,return) } } // namespace cln Is it wrong? And Why? Xinjian Zhao 2008-03-29 zhaoxinjian

4 6

What does _mulu32_high stand for in CLN?
by zhaoxinjian 29 Mar '08

29 Mar '08

Hi, Who can tell me something about _mulu32_high in CLN? Xinjian Zhao 2008-03-29 zhaoxinjian

3 2