jhersh, We are getting this same relocation error, but only when the code has been deployed; we are able to debug the code without an apparent issues. Does this make any sense to you? Is there more than one place where this needs to be set (ie. are there separate settings used for the build or dynamic linking when it is debugged vs. when it is downloaded)?
Are you maybe deploying the NonDebug version of your application?
I believe that we are deploying the debug version of the code… the path to the .out file is in the debug subdirectory under the project directory.
Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?
Regardless, I plan to try this build option tonight and I will let you know how it works out.
Thanks for your help.
That would be the same debug build, then.
Nope… in fact, the deployment happens by simply picking up that file, renaming it to FRC_UserProgram.out and FTPing it to the cRIO. It doesn’t even get relinked between the two methods of running.
Chances are you are just getting lucky when it works in debug and happens to align in a 24-bit window. Triple check that the -mlongcall flag is getting used. You should see it in the Build Console on each line (for compiling each file) as an option to “ccppc”.
-Joe
Thank you for your help… this fix worked!!!
Sorry, I’ve been ignoring this thread for a while and didn’t see this until just now.
The answer is yes.
When your DKM is loaded by the debugger, it will almost certainly be loaded into a different memory region than if it is loaded by the in-kernel facilities.
Edit: of course, if the module is compiled long call, it won’t matter. If it’s not, you have luck-of-the-draw.