Problem: MSVC creates different symbols for "extern const ex _ex0" if it is declared at top-level (inside GiNaC namespace) and if it is declared inside the body of a function (also inside GiNaC namespace). When linking, unresolved external symbols occur. Solution: Moved the declaration out of the body of the function Note: Instead of #include utils.h the same effect would probably be achieved by namespace GiNaC { extern const ex _ex0; } at the beginning of the file.
Hi, Jan! 2010/9/10 Jan private <jrheinlaender@gmx.de>:
Problem: MSVC creates different symbols for "extern const ex _ex0" if it is declared at top-level (inside GiNaC namespace) and if it is declared inside the body of a function (also inside GiNaC namespace). When linking, unresolved external symbols occur.
Solution: Moved the declaration out of the body of the function
I'm afraid your patch is incorrect. The ex.h file is public, and utlis.h is not (i.e. it's not supposed to be used by programs using GiNaC, and as you might notice it is not even installed). In other words, utils.h is supposed to contain internal functions/variables which should not be exposed to GiNaC users. Therefore including utils.h from ex.h is just plain wrong. Also, moving declaration of _ex0 from the ex::ex() ctor scope for all compilers is not wellcome. _ex0 should not be exposed to user code (in the past that caused quite a number of problems due to static initialization order fiasco).
Note: Instead of #include utils.h the same effect would probably be achieved by namespace GiNaC { extern const ex _ex0; } at the beginning of the file.
Please do so, and wrap that into _MSC_VER, and leave the code as is for other compilers. Thanks for your efforts. Best regards, Alexei
Problem: 1. MSVC creates different symbols for "extern const ex _ex0" if it is declared at top-level (inside GiNaC namespace) and if it is declared inside the body of a function (also inside GiNaC namespace). When linking, unresolved external symbols occur. 2. utils.h declares _num_1_p as const, but parse_binop_rhs.cpp omits the const. MSVC creates different symbols for the two versions, causing linking errors 3. parser.cpp mentions extern numeric* _num_1_p; extern ex _ex0; which cause linking problems Solution: 1. Moved the declaration out of the body of the function 2. added the const 3. omitted them because the code compiles without them (probably adding a const would also solve the problem) Note to 2: [basic.type.qualifier] says: \begin{quote} The cv-qualified or cv-unqualified versions of a type are distinct types; however, they shall have the same representation and alignment requirements (3.9)^46) 46) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions. \end{quote} It is not clear how it's possible for cv-qualified and non-cv-qualified type to have different mangled names without violating the above requirements, but anyway - MSVC can do it :-)
Hello Alexei, I found an error in this one so please use the attached file instead. Problem: 1. MSVC creates different symbols for "extern const ex _ex0" if it is declared at top-level (inside GiNaC namespace) and if it is declared inside the body of a function (also inside GiNaC namespace). When linking, unresolved external symbols occur. 2. utils.h declares _num_1_p as const, but parse_binop_rhs.cpp omits the const. MSVC creates different symbols for the two versions, causing linking errors 3. parser.cpp mentions extern numeric* _num_1_p; extern ex _ex0; which cause linking problems Solution: 1. Moved the declaration out of the body of the function (for MSVC only) 2. added the const 3. added the const for _ex0 and removed _num_1_p because it is not referenced in the file at all Note to 2: [basic.type.qualifier] says: \begin{quote} The cv-qualified or cv-unqualified versions of a type are distinct types; however, they shall have the same representation and alignment requirements (3.9)^46) 46) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions. \end{quote} It is not clear how it's possible for cv-qualified and non-cv-qualified type to have different mangled names without violating the above requirements, but anyway - MSVC can do it :-)
participants (2)
-
Alexei Sheplyakov
-
Jan private