Compile with MSVC 98% successful
I compiled ginac-1.5.7 with Microsoft Visual C++. You can find an account of my adventures on http://sourceforge.net/apps/mediawiki/ooo-imath/index.php?title=Installation... 56 of 57 tests passed. The one that didn't said: time_uvar_gcd.exe: timing univarite GCD GCD of relatively prime polynomials a and b degree(a) = 100, degree(b) = 50 mod_gcd : 1 5.96e-002 heur_gcd : 1 1.71e-002 sr_gcd: : 1 3.73e+001 Non-trivial GCD, degree(a) = 100, degree(b) = 100 mod_gcd : 51 1.70e-001 heur_gcd : 51 1.56e-002 heur_gcd (old) : 51 2.40e-001 sr_gcd: : 51 6.62e+000 sr_gcd (old) : 51 1.16e+001 Non-trivial GCD, degree(a) = 908, degree(b) = 908 mod_gcd : 1 1.66e+000 heur_gcd : 1 4.67e-001 Assertion failed: sfinder.found.size() == 1, file time_uvar_gcd.cpp, line 1621 Jan
Hello, On Tue, Aug 17, 2010 at 07:41:46AM +0430, Jan Rheinlaender wrote:
I compiled ginac-1.5.7 with Microsoft Visual C++. You can find an account of my adventures on http://sourceforge.net/apps/mediawiki/ooo-imath/index.php?title=Installation...
Could you please post patches instead of clumsy instructions like "edit file foo, find bar, replace with baz"? Warning: very few of them will be applied as is, see the comments below.
Therefore, go to the Makefile again and edit the following entry
I think editing automatically generated files is kind of pointless; cf. when fixing a bug one edits the source code, not binaries. Ditto for fiddling with *.lo files. Perhaps you need to instruct automake to use asm sources only when compiling with GCC.
cl_low.h defines extern "C" uint32 mulu32_high;
Which is allowed by the Standard (specifically, [dcl.link]). However, it also says: "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. [Note: because of the one definition rule (3.2), only one definition for a function or object with C linkage may appear in the program; that is, such a function or object must not be defined in more than one namespace scope." Thus moving those functions into the global namespace does actually make sense. However, it's better to prefix functions' names with "cl_" (or "cln_") to avoid possible name collisions.
cl_I.h declares extern cl_private_thing cl_I_constructor_from_UL(uint32 wert); extern cl_private_thing cl_I_constructor_from_Q(sint64 wert); somewhere in the file Comment out these declarations Replace them by the following at the beginning of the file: extern cln::cl_private_thing cl_I_constructor_from_UL(uint32 wert); extern cln::cl_private_thing cl_I_constructor_from_Q(sint64 wert);
Moving these functions outside of namespace cln is certainly unacceptable.
Edit cl_LF.h, comment out extern const cl_LF cl_I_to_LF (const cl_I& x, uintC len); and add extern const cln::cl_LF cl_I_to_LF (const cln::cl_I& x, uintC len); to the beginning of the file, outside the namespace cln
Ditto.
The other examples need more modifications of the source along the same lines to link. Only e.cc presents new problems Add #include "../src/float/lfloat/cl_LF.h" to the beginning of the file Comment out the extern cl_LF cl_I_to_LF(const cl_I&, uintC); declaration lower down
Header files in the src directory are private, and should be included only by other files in the src directory.
function.cpp: Change return (new GiNaC::power(*this, power_param))->setflag(status_flags::dynallocated | status_flags::evaluated); with return (power::power(*this, power_param)).setflag(status_flags::evaluated);
I'm afraid your variant is invalid, since it violates [basic.lookup.qual], specifically "1 The name of a class or namespace member can be referred to after the :: scope resolution operator (5.1) applied to a nested-name-specifier that nominates its class or namespace. During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. If the name found is not a class-name (clause 9) or namespace-name (7.3.1), the program is ill-formed." In the scope of function::power method definition the name `power' refers to the function::power itself, so it is not a class or a namespace name, and the program is invalid. Also this change breaks compilation with GCC 4.5 (for reason explained above). It's unacceptable, sorry.
polynomial/primes_factory.h: MSVC does not accept void * as argument of sizeof() Edit configure.ac and add a line AC_CHECK_SIZEOF(void*, 1). Run autoreconf and re-run configure.
This sounds a bit self-contradictory. AC_CHECK_SIZEOF(void*) certainly invokes sizeof(void*), so if your compiler doesn't grok sizeof(void*) (which I really doubt) AC_CHECK_SIZEOF(void*) is not going to work. On the other hand, if AC_CHECK_SIZEOF(void*) works, you don't actually need this trick.
External constants must be outside namespaces
I'm afraid the Standard does not enforce this (and we don't want to pollute the global namespace).
56 of 57 tests passed. The one that didn't said:
time_uvar_gcd.exe: timing univarite GCD GCD of relatively prime polynomials a and b degree(a) = 100, degree(b) = 50 mod_gcd : 1 5.96e-002 heur_gcd : 1 1.71e-002 sr_gcd: : 1 3.73e+001 Non-trivial GCD, degree(a) = 100, degree(b) = 100 mod_gcd : 51 1.70e-001 heur_gcd : 51 1.56e-002 heur_gcd (old) : 51 2.40e-001 sr_gcd: : 51 6.62e+000 sr_gcd (old) : 51 1.16e+001 Non-trivial GCD, degree(a) = 908, degree(b) = 908
Should be: Non-trivial GCD, degree(a) = 1000, degree(b) = 1000 So it looks like inputs are incorrect (I don't know why). Best regards, Alexei
Hello Alexei,
Could you please post patches instead of clumsy instructions like "edit file foo, find bar, replace with baz"? Warning: very few of them will be applied as is, see the comments below. sorry, I am just trying to compile GiNaC somehow for my own purposes. I am not a good enough programmer to deal with all the details you mentioned (although I will try to as far as my abilities go). So if someone wants to build on my "adventures", he can go ahead, otherwise just leave it.
Is anybody except me interested in compiling GiNaC with MSVC, anyway? In any case, how do I post patches? Thank you for taking the time to comment on my post in this length! Regards, Jan
Hallo Jan, 2010/8/23 Jan private <jrheinlaender@gmx.de>
Hello Alexei,
Could you please post patches instead of clumsy instructions like "edit file foo, find bar, replace with baz"? Warning: very few of them will be applied as is, see the comments below. sorry, I am just trying to compile GiNaC somehow for my own purposes. I am not a good enough programmer to deal with all the details you mentioned (although I will try to as far as my abilities go). So if someone wants to build on my "adventures", he can go ahead, otherwise just leave it.
Is anybody except me interested in compiling GiNaC with MSVC, anyway?
I am interresed, actually I wanted to do it myself, but You were faster ;-) In second half of October I even can help. Cheers, Peter
In any case, how do I post patches?
Thank you for taking the time to comment on my post in this length!
Regards, Jan
_______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
participants (3)
-
Alexei Sheplyakov
-
Jan private
-
Peter Grobarcik