Hi! On 09/10/2010 05:20 AM, Jan private wrote:
Problem: MSVC creates different symbol names for 'extern "C" uint32 mulu32_high' when declared inside the cln namespace, and when defined inside it. Linking produces "unresolved external symbol" errors.
----- 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, sucha function or object must not be defined in more than one namespace scope." -----
Solution: Moved declarations into global namespace and prefixed with cln_
Thanks very much for submitting the patch. I see, however, three objections: 1) As it is, it won't work. Recursively greping for mulu32_high and those other extern "C" variables under src/base/ reveals that they are also used inside the assembler modules. Which is, of course, the entire reason why they must have C language linkage! This can should be fixed. 2) My reading of this section is that MSVC has a bug: "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." What do you mean when you write "Which is allowed by the standard [...]. However..."? Do you claim that your patch is fixing a problem in CLN or that it is working around a bug in MSVC? 3) I don't have access to MSVC. We've received many patches for CLN (and GiNaC, too) and applied most of them. Yet, it is still unclear to me what the status under MSVC is. Since patches keep coming in, I suppose that things are still not fully working. The way I see it is this: There are two major free compilers out there (GCC and Clang) that don't have any problem compiling the current git HEAD of both packages and it still looks like we are pampering around problems in an expensive piece of crap by a really big and annoying software manufacturer. This bothers me. Jan, please don't take this personal but you have to understand my position as one outsider who is irritated by a time-consuming continuous stream of little patches for compilation with MSVC. I will keep accepting patches for whatever compiler as long as they are not too disruptive. But I will only do so if the submitter explains what is accomplished with it: * Which compiler version has been used? * What exactly does the patch fix (a warning, a compile-time error, miscompilation)? * Are more workarounds necessary (compiler options, etc.)? You are, of course, more than welcome to review your patch under these criteria and resubmit it. Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>