Sorry for the rapid-fire. I'm up late and the ideas are only trickling out.
It appears that the code doesn't think __cplusplus is defined. That is odd. nvcc claims (or, it used to) that it always runs the code through a C++ compiler at the end of the day, so why it wouldn't have __cpluplus defined is beyond me. David On Mon, Feb 18, 2013 at 12:51 AM, David Mertens <dcmertens.p...@gmail.com>wrote: > Sorry, meant to reply-all. > > David > > > ---------- Forwarded message ---------- > From: David Mertens <dcmertens.p...@gmail.com> > Date: Mon, Feb 18, 2013 at 12:51 AM > Subject: Re: Apparent linkage conflicts with dVAR; dXSARGS; when compiled > using nvcc > To: bulk88 <bul...@hotmail.com> > > > bulk88 - > > I've updated the original gist with a new file that includes the direct > C(++) code as preprocessed by nvcc. The two look identical to me. Should I > try to bump-up the verbosity of the compiler? > > David > > > On Mon, Feb 18, 2013 at 12:25 AM, bulk88 <bul...@hotmail.com> wrote: > >> ** >> 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? >> > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
