Re: Apparent linkage conflicts with dVAR; dXSARGS; when compiled using nvcc

David Mertens wrote:
> Hello everybody -
>
> I recently resuscitated CUDA::Minimal, a module that provides basic 
> memory allocation and memory transfer functionality for CUDA (i.e. 
> video card) parallel programming. Note, you must write your own CUDA 
> kernels separately; I recommend writing them in XS wrapper code, using 
> ExtUtils::nvcc and can answer questions if you're interested.
>
> When using ExtUtils::nvcc, your code gets compiled through a C++ 
> compiler. I seem to have struck a problem with how XS handles its dVAR 
> and dXSARGS declarations in the Boot section and in other sections. 
> The applicable error can be found here: 
> https://github.com/run4flat/perl-CUDA-Minimal/issues/7. The actual C 
> code that leads to this error (generated from the XS code on my 
> machine) is given in this gist: https://gist.github.com/run4flat/4974702.
>
> The problem is a linkage conflict in the declaration for Perl__notused 
> on lines 163 
> <https://gist.github.com/run4flat/4974702#file-minimal-c-L163> and 329 
> <https://gist.github.com/run4flat/4974702#file-minimal-c-L374>, which 
> I presume is embedded in dVAR or dXSARGS. However, I'm left scratching 
> my head as to why the linkage would differ between these two. Based on 
> my understanding of how extern "C" works 
> <http://stackoverflow.com/questions/10458545/what-is-extern-linkage-and-with-c-language-linkage>, 
> there is no difference that I can see. That is, there is no difference 
> in the linkage specification for the two, because the extern "C" on 
> line 369 does not have curly braces and therefore only effects the 
> declaration of the function definition. It should not impact the 
> declarations of any variables.
>
> Anybody have any idea what's causing this linkage specification 
> problem, and how I might fix it?
>
> Thanks!
> David
I think dVAR becomes dNOOP which is 
http://perl5.git.perl.org/perl.git/blob/f6fe275c937ceb508cdcfd033ce162e1fa01989e:/perl.h#l354. 
Note a C++ and a C version of that macro. Can you post the preprocessed 
version of the .c file or have you looked at the preprocessed version 
for clues as to what happened?