On 11/7/2013 2:10 PM, Arsen Chaloyan wrote:
On Thursday, November 7, 2013 4:27 AM, Jeff Trawick
<[email protected]> wrote:
On Thu, Nov 7, 2013 at 12:29 AM, William A. Rowe Jr.
<[email protected] <mailto:[email protected]>> wrote:
On Tue, 5 Nov 2013 17:49:22 -0800 (PST)
Arsen Chaloyan <[email protected] <mailto:[email protected]>>
wrote:
>
> These errors are caused by the use of the new Platform Toolset v120
> which gets installed with VS2013. More specifically, the problem is
> in the function cast wrappers defined in apr_atomic.c and used only
> for Win32 (x86) platform. Taking out the function casts helps
resolve
> the link errors with a penalty of having warning messages instead.
Each time I've seen such issues, there is some -Define flag to
circumvent the silly MSVC design team's choices. Please look into
the headers to see if there is a more straightforward workaround to
revert to the 'classic' behavior first.
> Also, they probably have a support forum for early VS2013 adopters.
They might be able to provide the right solution to work across
releases. (With no more warnings; there are enough of those already
to make it tedious to spot when new ones arrive.)
Well, the problem is actually not as complicated as it may have
seemed. Let me clarify a bit.
In the Platform Toolset v120 (VS2013), the function
InterlockedIncrement() and the friends are specified with
#pragma intrinsic(_InterlockedIncrement)
for all the platforms, including x86. Whereas in the former versions
of SDK, the intrisnic pragma directive is used for x64 but NOT for
x86. I can clearly see the difference comparing the header files. And
there doesn't seem to be any defines which would allow us to revert
the behavior.
Thus, the function casts introduced in apr_atomic.c resolve/work for
former versions but cause link errors with v120 since the function
calls for x86 are now intrinsic as they have been for x64.
Given all these differences between platforms and toolset versions,
I'd simply not use the function cast wrappers but still take care of
the differences between APR and underlying Windows interfaces. The
attached patch allows to build the APR library without any warnings or
errors on/for both x86 and x64. Tested using VS2005, VS2010, and
VS2013. Should also work for VS2008 and VS2012, not sure about VC6,
though. I'd also combine the cases (#ifdefs) for x86 and x64 in
apr_atomic.c.
I'd personally prefer you specifically target _MSC_VER >= 1800 with this
since I know it works just fine as-is on VC6, 9, 10 & 11.
Regards,
Gregg
