Hi! On Sun, Apr 19, 2009 at 11:26:26PM +0100, Michael Goffioul wrote:
The main problem when compiling packages with VC++ is not the compiler itself, which is pretty C/C++ compliant,
Actually CLN itself is not quite standard compliant. It used to rely on non-standard compiler and linker features, such as GNU inline semantics (which is IMHO much better than one imposed by C++ and C99), weak symbols support, etc. Although most of these issues are already fixed there are definitely quite a number of GCC'isms left. [skipped auto* tools rant]
For the specific case of CLN, there were a couple of issues I also had to take care of: 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.
AFAIK struct and class are synonymous, the standard says: \begin{quote} [class] 4 A structure is a class defined with the class-key struct; its members and base classes (clause 10) are public by default (clause 11). \end{quote} Anyway, if your compiler doesn't care about standards, please submit a patch. Note: please take care to write proper comments (i.e. why patch is necessary at all, what problem[s] it solves, etc.) and not break compilation on a primary platform (GNU/Linux). Also it would be nice if you separate unrelated changes and post them as individual patches (as opposed to all-in-one patch).
The same happen for const/non-const (forward declare as non-const, but define as const).
Very interesting. [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} I don't quite understand how it's possible for cv-qualified and non-cv-qualified type to have different mangled names without violating the above requirements. Anyway, please submit a patch.
- 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;
This is definitely a compiler bug.
for instance in number.h, I had to move the "extern" statements of CL_DEFINE_LONG_CONSTRUCTOR out of the method bodies.
I'm afraid such an approach is unacceptable. Those functions are intended for internal usage only, and they are hidden from users for a reason (otherwise it would be very difficult to guarantee binary compatibility). We could export them only for msvc, but then we can't guarantee binary (and source-level) compatibility any more. Best regards, Alexei