| Summary: | Compilation errors with MSVC after recent changes to 'cairo-path-stroke-traps.c' | ||
|---|---|---|---|
| Product: | cairo | Reporter: | John Emmas <johne53> |
| Component: | general | Assignee: | Chris Wilson <chris> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | fanc999 |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Another variant to solve the msvc compilation problem
A third proposal for solving the MSVC compilation issue |
||
Created attachment 107945 [details] [review] Another variant to solve the msvc compilation problem Also working and more similar to what was there before. Just want to confirm that Hans's variant does build okay with MSVC and it does produce correctly initialised arrays. One question... will this strategy work okay for other platform / compiler architectures (e.g. big-endian)? I suspect the answer's probably "yes" but I just wanted to raise that question. Thanks Hans, for the prompt work! Following up... Can we incorporate Hans's fix into the official code soon? I just updated a few minutes ago (from git master) but I'm still seeing the original code which doesn't compile :-( Created attachment 109394 [details] [review] A third proposal for solving the MSVC compilation issue For completeness, here's a 3rd solution for this problem (originally proposed on the mailing list by Thomas Berg). I've applied this patch locally and I can confirm that this one also compiles and links successfully. Surely one of these proposals must now be acceptable?? Comment on attachment 107945 [details] [review] Another variant to solve the msvc compilation problem Hi, I can confirm too that this patch works for me (Visual Studio 2008+, which also gets this problem). The issue here is that Visual Studio 2005+ is quite strict on type conversions (so it wants code to be clear enough on conversions), and I think it makes sense from a correctness and a security point of view. Although the code might not look that nice, but I think as Hans mentioned, it is consistent with the rest of Cairo. Please consider this patch, especially as Cairo does need some update and work on the Windows side, and making it buildable with Visual Studio would be really helpful for that work. Thanks very much for your time, with blessings! If Chris can't find time to deal with this, would it speed things up to re-assign it to someone else? Hans' patch committed to trunk. To ssh://git.cairographics.org/git/cairo 2c5af59..56da7ad master -> master This looks eligible to backport to 1.14 as well, if it's needed there. (In reply to Bryce Harrington from comment #7) > Hans' patch committed to trunk. > > To ssh://git.cairographics.org/git/cairo > 2c5af59..56da7ad master -> master > > This looks eligible to backport to 1.14 as well, if it's needed there. Hi Bryce, Sorry for the delay in replying. Master is now building fine again - but yes, the patch needs to get applied to 1.14 as well. Any chance that this could get done in the next day or two? Thanks, John Cherry-picked to the 1.14 branch: To ssh://git.freedesktop.org/git/cairo f6fd372..b2333fd 1.14 -> 1.14 Just confirming that 1.14 is now buildable with MSVC again. Thanks. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Firstly, apologies. I'm not sure whether this needs to get filed under 'general' or under 'win32-backend' but anyway, here it is... Since updating from git master about a week ago (ver 1.13.1) I can no longer compile 'cairo-path-stroke-traps.c' with Microsoft VC8. I get errors at lines 302, 303, 464 and 465. As an example, line 302 looks like this:- cairo_point_t t[] = { in->point, *inpt, *outpt } Given that 'in->point', '*inpt' and '*outpt' are all structs, I suspect the problem is that the compiler would need to generate a default copy c'tor for 'cairo_point_t'. MSVC does this when compiling as C++ but not when compiling as 'C'. Unfortunately, if I change my project to build as C++ I just get a whole slew of other errors elsewhere. So currently, I can't compile as 'C', nor as C++. The errors at lines 302 and 303 can be fixed as follows. I'm not claiming that my fix is the most elegant one (and of course, somebody will need to verify that it fulfils the original intention) but it does at least compile!! If somebody wants to come up with a more elegant solution, this should at least tell them what's going wrong:- 1) Remove lines 302 and 303 and replace with the following code:- cairo_point_t t[3]; cairo_point_t e[4]; memcpy( &t[0], &in->point, sizeof(cairo_point_t) ); memcpy( &t[1], inpt, sizeof(cairo_point_t) ); memcpy( &t[2], outpt, sizeof(cairo_point_t) ); memcpy( &e[0], &in->cw, sizeof(cairo_point_t) ); memcpy( &e[1], &in->ccw, sizeof(cairo_point_t) ); memcpy( &e[2], &out->cw, sizeof(cairo_point_t) ); memcpy( &e[3], &out->ccw, sizeof(cairo_point_t) ); 2) It looks like the same fix would probably work for lines 464 and 465. Hope that helps, John