LabVIEW
How can I load a dll to cRIO-908x ( OS:PharLap )
Solved!
Great to hear that you solved it. Alternatively another possibility is to compile the C code with "Multi-threaded Debug /MTd" rather than "Multithreaded Debug DLL /MDd" in the Code Generation settings, but not sure that is gonna work with VC 2010. The C runtime is then linked into the resulting DLL, but mainly the startup stub of that C runtime makes use of some Windows APIs that are not compatible with older Windows versions and therefore likely not implemented in Pharlap ETS.
It's a good alternative for DLLs that you want to distribute to Windows clients though as you don't have to worry about getting the C runtime redistributable installed on the client machine, at the expense of a larger DLL. But no matter what you do, VC2010 will not create DLLs that generally run on older Windows OS systems. It probably will barely support Windows XP and VC2012 likely dropped that.
The DLL was compiled with MS VC 2015. If you chose to link it with the static C runtime library then Microsoft changed how they do that and added a new dependency that requires the installation of the C runtime library anyhow. However the MS VC2015 C runtime library installer will not be able to install onto the Pharlap system since it assumes at least a Windows 7 or newer system. The Pharlap system is barely Windows 2000 API compatible. So you most likely will have to find a way to use an older MS VC version to compile that DLL in order to get it to work for the cRIO system. MS VC2008 and VC 2010 are known to work even when you use the dynamic link runtime version since NI has ported the Microsoft Visual C runtime library for these two compilers to their Pharlap targets and you can install support for them in the software installation section for your target (usually it is already installed as part of the standard recommended system setup).
Since NI moved away from Pharlap OSes for almost all of their targets it is not likely that they will invest many more resources to create a new C runtime distribution for a newer Visual C version. That is an absolutely non-trivial exercise with several legal issues, since the copyright for the source code for the MS C runtime is owned by Microsoft and you can't just go and create your own version of that library and distribute it at will.
Not sure if you missed it, but the last post was talking about the Linux RT OS, not Pharlap. Really Rlara should make a new thread, and in a possibly post in a subforum that speaks their native language, if it is not English.
I missed that indeed! Only looked at the topic and downloaded the compressed archive. Didn't expect anyone to think they could load a DLL on a Linux based system! 
So no, DLLs are Windows only files (and to some limited extend Pharlap ETS compatible) but for Linux or any other OS they mean as much as an Egyptian hyroglyph to a modern person: Just a bunch of weird strokes and bytes!
@rolfk wrote:
So no, DLLs are Windows only files (and to some limited extend Pharlap ETS compatible) but for Linux or any other OS they mean as much as an Egyptian hyroglyph to a modern person:
Oh but if you have Wine installed in Linux then you can run Windows binaries. I have yet to try to run a DLL in Wine, on RT Linux, but I was able to run Windows programs with Wine on RT Linux.
https://decibel.ni.com/content/docs/DOC-48792
My success was limited to 64-bit binaries, but if you have the source then I assume you should be able to compile it for that target.
Yes of course, but that would not work with the LabVIEW embedded runtime on the cRIO. That is a Linux executable and that will not run in Wine. And installing LabVIEW for Windows runtime under Wine may work with a lot of humbo mumbo magic but it would not be recognized by the LabVIEW RT system on your PC as a valid target.
Would leave the highly involved solution of running the Windows DLL under a special Windows executable running under Wine and useing some inter process communication based on for instance TCP/IP to proxy that to the Linux LabVIEW runtime. But I think reinventing the wheel would be a much simpler and less useless exercise than trying to get such an involved architecture working. Since the code for the DLL in question is open source on GIT going to recompile the DLL into a Linux RT shared library for x64 is definitely simpler albeit without some serious Linux and C compiler knowledge also an exercise in vain.
The DLL is not. You have to get the x64 bit version of the Linux shared library and there is a certain chance that you have to recompile it with the C toolchain that you can download from NI. Linux is not just Linux but there are many differences between distributions in terms of what libraries are installed, which flavor of a particular library is used and there are even complete subsystems different between distributions.
The NI Linux RT system is no difference here. In fact it is derived from a distribution that is more centered around embedded Linux solutions than the standard desktop Linux version that big guys like RedHat, Suse, Ubuntu and similar target use. And it has been modified by NI to add specific realtime features directly into the kernel.
Also dependencies under Linux can be an extra problem. For any non trivial library this can result in a whole chain of extra libraries that need to be installed and it's not always possible to get that fully done due to conflicts of different components requiring different versions of libraries.
So even if they have full Linux support, chances are definitely there, that you can not use their precompiled x64 version of the shared library but have to recompile the source code for your specific target with the according toolchain.
And the fact remains that your DLL has absolutely no meaning for the Linux system, you do need the .so file instead.
