You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Arsen Chaloyan <ac...@yahoo.com> on 2013/11/06 02:49:22 UTC
Link errors in apr_atomic with VS2013
Hi,
While building the APR library with VS2013 for Win32(x86) platform, the following link errors are encountered.
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedIncrement referenced in function _apr_atomic_inc32@4
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedExchangeAdd referenced in function _apr_atomic_add32@8
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedExchange referenced in function _apr_atomic_set32@8
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedDecrement referenced in function _apr_atomic_dec32@4
apr_atomic.obj : error LNK2019: unresolved external symbol __InterlockedCompareExchange referenced in function _apr_atomic_cas32@12
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.
The build for x64 platform is not affected.
Would you be interested in addressing this issue in the APR mainstream in one or the other way?
Regards,
Arsen
Re: Link errors in apr_atomic with VS2013
Posted by Gregg Smith <gl...@gknw.net>.
On 11/12/2013 10:33 AM, Gregg Smith wrote:
> On 11/12/2013 10:27 AM, William A. Rowe Jr. wrote:
>> On Fri, 8 Nov 2013 11:00:18 -0800 (PST)
>> Arsen Chaloyan<ac...@yahoo.com> wrote:
>>
>>> Anyway, if it turns out the change has to be #ifdef-ed, which is most
>>> likely, then testing _MSC_VER only is not enough or appropriate.
>>> Please note, if one uses VS2013 (_MSC_VER == 1800), it doesn't
>>> necessarily mean that the Platform Toolset v120 is being used.
>>> Starting with VS2010, it's possible to choose one of the available
>>> Platform Toolsets to build with.
>>>
>>> So, either _MSC_VER_FULL should be used or a new preprocessor
>>> definition can be added, something like
>>> _MSC_PT_VER=$(PlatformToolsetVersion) with further reference to
>>> _MSC_PT_VER>= 120.
>> Does this change apply to all flavors of the Platform Toolset? It
>> sounds like that might be configured w/ older or later versions of MSC.
>>
>> E.g. can we simply look for #ifdef _MSC_PT_VER and presume the proposed
>> patch will work correctly
> No, as it doesn't exist nor do I see a good way to detect the SDK
> version in use.
>
> I gave the proposed patch a try on VC6/2003R2 SDK, 2008 and 2012, it
> worked on all three without warnings. Arsen's tested on 2005, 2010 &
> 2013, that leaves only 2003 untested.
Get my response on the list, not just to Bill. ARG! This list setup.
Re: Link errors in apr_atomic with VS2013
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Fri, 8 Nov 2013 11:00:18 -0800 (PST)
Arsen Chaloyan <ac...@yahoo.com> wrote:
> Anyway, if it turns out the change has to be #ifdef-ed, which is most
> likely, then testing _MSC_VER only is not enough or appropriate.
> Please note, if one uses VS2013 (_MSC_VER == 1800), it doesn't
> necessarily mean that the Platform Toolset v120 is being used.
> Starting with VS2010, it's possible to choose one of the available
> Platform Toolsets to build with.
>
> So, either _MSC_VER_FULL should be used or a new preprocessor
> definition can be added, something like
> _MSC_PT_VER=$(PlatformToolsetVersion) with further reference to
> _MSC_PT_VER >= 120.
Does this change apply to all flavors of the Platform Toolset? It
sounds like that might be configured w/ older or later versions of MSC.
E.g. can we simply look for #ifdef _MSC_PT_VER and presume the proposed
patch will work correctly?
Re: Link errors in apr_atomic with VS2013
Posted by Arsen Chaloyan <ac...@yahoo.com>.
Agree we should be careful with backward compatibility, but I unfortunately don't have anything below VS2005 to test against.
Anyway, if it turns out the change has to be #ifdef-ed, which is most likely, then testing _MSC_VER only is not enough or appropriate. Please note, if one uses VS2013 (_MSC_VER == 1800), it doesn't necessarily mean that the Platform Toolset v120 is being used. Starting with VS2010, it's possible to choose one of the available Platform Toolsets to build with.
So, either _MSC_VER_FULL should be used or a new preprocessor definition can be added, something like _MSC_PT_VER=$(PlatformToolsetVersion) with further reference to _MSC_PT_VER >= 120.
Regards,
Arsen
On Friday, November 8, 2013 3:58 AM, Gregg Smith <gl...@gknw.net> wrote:
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
Re: Link errors in apr_atomic with VS2013
Posted by Gregg Smith <gl...@gknw.net>.
On 11/7/2013 2:10 PM, Arsen Chaloyan wrote:
>
>
> On Thursday, November 7, 2013 4:27 AM, Jeff Trawick
> <tr...@gmail.com> wrote:
> On Thu, Nov 7, 2013 at 12:29 AM, William A. Rowe Jr.
> <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
>
> On Tue, 5 Nov 2013 17:49:22 -0800 (PST)
> Arsen Chaloyan <achaloyan@yahoo.com <ma...@yahoo.com>>
> 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
Re: Link errors in apr_atomic with VS2013
Posted by Arsen Chaloyan <ac...@yahoo.com>.
On Thursday, November 7, 2013 4:27 AM, Jeff Trawick <tr...@gmail.com> wrote:
On Thu, Nov 7, 2013 at 12:29 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
On Tue, 5 Nov 2013 17:49:22 -0800 (PST)
>Arsen Chaloyan <ac...@yahoo.com> 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.
Re: Link errors in apr_atomic with VS2013
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Nov 7, 2013 at 12:29 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:
> On Tue, 5 Nov 2013 17:49:22 -0800 (PST)
> Arsen Chaloyan <ac...@yahoo.com> 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.)
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Link errors in apr_atomic with VS2013
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 5 Nov 2013 17:49:22 -0800 (PST)
Arsen Chaloyan <ac...@yahoo.com> 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.