I'm building a package tested for CUDA 9,10 from source, trying to compile it for CUDA11.
I've already changed gencode=arch=compute_70 (was set on 30), and added
target_link_libraries(tsnecuda ${CUDA_cusparse_LIBRARY})
Unfortunately, I still get
tsne-cuda/src/util/math_utils.cu(153): error: identifier "cusparseScsr2csc" is undefined
tsne-cuda/src/util/math_utils.cu(165): error: identifier "cusparseXcsrgeamNnz" is undefined
tsne-cuda/src/util/math_utils.cu(195): error: identifier "cusparseScsrgeam" is undefined
3 errors detected in the compilation of "tsne-cuda/src/util/math_utils.cu".
CMake Error at tsnecuda_generated_math_utils.cu.o.cmake:276 (message):
Error generating file
tsne-cuda/build/CMakeFiles/tsnecuda.dir/src/util/./tsnecuda_generated_math_utils.cu.o
Is there a chance the build process somehow ignores my target_link_libraries? Should I add something else?
Undefined identifier is a compilation issue, not a linking issue.
At least part of the problem here is that CUDA deprecated and removed some functionality from cusparse, including cusparse<t>csr2csc(). The code would need to be rewritten to compile correctly under the latest versions of CUDA 11.x.
For example, for csr2csc, the call to cusparseScsr2csc might be refactored to use this function instead.
One example of deprecation/removal notice for cusparse<t>csr2csc is given here.
Related
If I compile the following piece of code:
using foo [[deprecated]] = char;
with nvcc v10.2.89, and with -std=c++14, I get:
warning: attribute does not apply to any entity
But this doesn't happen with -std=c++11. Why am I getting this warning at all? This seems to be valid C++14.
See this on GodBolt.
I suspect this is a bug in that version of NVCC. With CUDA 11.x versions of NVCC, this doesn't seem to happen. It seems you'll need to upgrade, or have your users upgrade.
Thje error that I got ae as follows
fftw_oct.f90:(.text+0x26a): undefined reference to `fftw_alloc_real'
/usr/local/bin/ld: fftw_oct.f90:(.text+0x3a7): undefined reference to `fftw_alloc_complex'
/usr/local/bin/ld: fftw_oct.f90:(.text+0x4fb): undefined reference to `fftw_alloc_complex'
Is this error arises due to GNU LINKER ?
The linker doesn't invent references; if you have an undefined reference, it means you (or something you linked) made a reference to something you didn't link.
That can mean a couple of things - for example, you could be missing a library on your link line (check for missing -l flags), or that something you compiled contained conditionals that weren't enabled (#ifdef and the like), so those symbols were omitted.
If it didn't give you heck at compile time (check your warnings), you likely have a header that contains declarations of the missing symbols. That should help you narrow down the location of their implementations.
Recently iam trying to update my angular project from 8 to 9. While updating i also updated wijmo from wijmo/wijmo to #grapecity/wijmo package as it supports IVY.
But after the completing the upgradation, i can able to compile the application but i am getting the following error at run time
global-error-handler.service.ts:43 Error: Uncaught (in promise): TypeError: (0 , t[n]) is not a function
TypeError: (0 , t[n]) is not a function
at backend.js:61
at Reflect.<anonymous> (backend.js:61)
at push../node_modules/#grapecity/wijmo.angular2.grid.detail/__ivy_ngcc__/index.js.__decorate (index.js:28)
at index.js:53
at Object../node_modules/#grapecity/wijmo.angular2.grid.detail/__ivy_ngcc__/index.js (index.js:53)
at __webpack_require__ (bootstrap:84)
I'd like to get some more info about this error. The quick thing to check is property initialization order. In Ivy, the properties are interpreted as they are specified in markup (previously wijmo controlled how they were interpreted). So you can break components by setting certain properties before others.
For example, if I tried to set the selectedIndex on a combobox BEFORE I set the data source, then the app would break at runtime because there are no items in the list to select yet.
More info here: https://www.grapecity.com/wijmo/docs/GettingStarted/Angular-Components#property-initialization-order-in-angular-9-ivy-and-higher
The next thing to check is component decorators (if you are inheriting our components). There are some breaking changes in decorators in Ivy.
For example, you might need to add {descendants: true} to ContentChildren queries.
Or you might need to add an #Injectable decorator to your class.
You can read more about breaking changes in Ivy and how to fix them here: https://angular.io/guide/ivy-compatibility-examples
But please feel free to contact us to work directly: wijmoexperts#grapecity.com
On migration to lit-element version 0.6.0. If I use
<script src="node_modules/#webcomponents/webcomponentsjs/webcomponents-bundle.js"></script>
in the header part of my document. I have the following error :
Uncaught (in promise) TypeError: Cannot read property 'previousSibling' of null
at NodePart._commitText (parts.ts:255)
at NodePart.commit (parts.ts:216)
at TemplateInstance.update (template-instance.ts:56)
at NodePart._commitTemplateResult (parts.ts:283)
at NodePart.commit (parts.ts:220)
at render (render.ts:48)
at Function.render (shady-render.ts:160)
at HTMLElement.update (lit-element.ts:44)
at HTMLElement._validate (updating-element.ts:600)
at HTMLElement._invalidate (updating-element.ts:574)
I couldn't trace where this error came from as the errors stack is huge and involves a lot of asynchronous calls. Also I tried to reproduce a minimal example, but same, I couldn't emulate the same error message.
The consequence of this error is a complete failure to load some custom elements (to the point the application is unusable).
Now If I change the header script with this one :
<script src="node_modules/#webcomponents/webcomponentsjs/webcomponents-loader.js"></script>
The error just vanishes.. but now the following warning message appears in the console:
Incompatible ShadyCSS version detected. (shady-render.ts:42)
Please update to at least #webcomponents/webcomponentsjs#2.0.2 and#webcomponents/shadycss#1.3.1.
It's a funny message because my project is using webcomponentsjs version 2.1.2 and shadycss version 1.5.2 already.
Besides this warning message the css directives #apply are completely ignored resulting in an interface not using any flex properties (I let you imagine the mess).
Now this is a behavior I really can't understand even though I spent full afternoon digging into documentation and stuff. I summon your help.
There is a known issue with ShadyCSS that was introduced in 0.11.3, so that may be causing your problems with shady-render. I think the fix is already in so it should be resolved with 0.11.4
If you are using LitElement, you should probably be using lit-html version 0.11.2, which is what lit-element itself uses. Otherwise there's a reasonable chance that you are using two different versions, which may also explain some problems.
I can't reproduce your issues though: codepen.io/ruphin/pen/qMyMVO?editors=1010
The only explanation I can come up with is that webcomponents-bundle.js works, which triggers ShadyRender to be used, which breaks. When you switch to webcomponents-loader.js the polyfills don't work for some reason, which causes ShadyRender to not be used and explains why you don't get the error, but get the incompatible polyfill warnings, and don't get properly polyfilled CSS. I don't know why this is happening though, both versions of the polyfill should work, although I generally recommend using -bundle.
It would help if I knew on what browser/version you are seeing the problem.
A flash application in flash builder is currently throwing this error:
ReferenceError: Error #1065: Variable
is not defined.
Not telling me which variable it is that's not defined, but note there are two spaces between 'variable' and 'is'. and it gives me some more feedback as to what lines of code are having trouble, but those lines are all within the actual flash/mxml packages and not any of the files in my own project.
I suspect it's related to my php data/services, but I don't see what variable would not be defined. I'm not very familiar with debugging, so I'm not sure how to determine with it where the problem is cropping up.
at global/flash.utils::getDefinitionByName()
at mx.utils::DescribeTypeCache$/describeType()[E:\dev\4.x\frameworks\projects\framework\src\mx\utils\DescribeTypeCache.as:106]
at com.adobe.serializers.utility::TypeUtility$/getType()[/Users/sameer/depot/flex/ide_builder/com.adobe.flexbuilder.dcrad/serializers/src/com/adobe/serializers/utility/TypeUtility.as:90]
at com.adobe.serializers.utility::TypeUtility$/assignProperty()[/Users/sameer/depot/flex/ide_builder/com.adobe.flexbuilder.dcrad/serializers/src/com/adobe/serializers/utility/TypeUtility.as:516]
at com.adobe.serializers.utility::TypeUtility$/convertToStrongType()[/Users/sameer/depot/flex/ide_builder/com.adobe.flexbuilder.dcrad/serializers/src/com/adobe/serializers/utility/TypeUtility.as:498]
at com.adobe.serializers.utility::TypeUtility$/convertListToStrongType()[/Users/sameer/depot/flex/ide_builder/com.adobe.flexbuilder.dcrad/serializers/src/com/adobe/serializers/utility/TypeUtility.as:454]
at com.adobe.serializers.utility::TypeUtility$/convertResultHandler()[/Users/sameer/depot/flex/ide_builder/com.adobe.flexbuilder.dcrad/serializers/src/com/adobe/serializers/utility/TypeUtility.as:367]
at mx.rpc.remoting::Operation/http://www.adobe.com/2006/flex/mx/internal::processResult()[E:\dev\4.x\frameworks\projects\rpc\src\mx\rpc\remoting\Operation.as:316]
at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::resultHandler()[E:\dev\4.x\frameworks\projects\rpc\src\mx\rpc\AbstractInvoker.as:313]
at mx.rpc::Responder/result()[E:\dev\4.x\frameworks\projects\rpc\src\mx\rpc\Responder.as:56]
at mx.rpc::AsyncRequest/acknowledge()[E:\dev\4.x\frameworks\projects\rpc\src\mx\rpc\AsyncRequest.as:84]
at NetConnectionMessageResponder/resultHandler()[E:\dev\4.x\frameworks\projects\rpc\src\mx\messaging\channels\NetConnectionChannel.as:547]
at mx.messaging::MessageResponder/result()[E:\dev\4.x\frameworks\projects\rpc\src\mx\messaging\MessageResponder.as:235]
look at line 106 for DescribeTypeCache.as There will likely be two variables, one of them is undefined