LabVIEW
Running dll file on RT target
Not normally! gcc is a huge software project. While it is modularized and does allow to compile support of various backends into it (each processor architecture and OS ABI is a different backend module) that is usually not done since most users who install gcc on their Linux box do that to compile software for their own box, not cross compiling for other computer architectures.
So your standard Ubuntu Linux or whatever installation on your PC can have a gcc installation (if you installed development support) but that gcc compiler can't just create binary files for any possible computer platform out there. Such a compiler installation would get HUUUUUGE and multi-architecture support in gcc is absolutely not trivial to use!
The most trivial solution is to install the development support on and for the box you want to create the code for and compile it on that box. This can be done with the NI Linux RT controllers since NI has added develop packages for the two NI Linux varieties to their opkg package feeds.
A somewhat more complex solution is to install a cross compiler toolchain on your Windows PC like this I already mentioned twice before or if you rather prefer a IDE you can install the Eclipse based IDE which comes with the two cross compiler toolchains for both NI Linux architectures.
Here is a link for you to read: http://www.ni.com/tutorial/52578/en/
This is the forum for the NI Linux platform. It has many documents and feeds about the topic and you should read through some of them for sure before repeating your pleads to make this work for you.
As a summary: Your standard gcc installation on your Linux PC can NOT generate shared libraries for any of the NI Linux RT controllers. You need a special cross compiler version of gcc for that, either on your Linux or Windows host PC. Such a cross compiler must have been created specifically for the host you want to run it on (a Linux executable obviously won't run on Windows and vice versa) and with the desired architecture support enabled (ARM code generation for the myRIO).
Or you can install the develop package on the myRIO and then compile your shared library there.
Your information is insufficient to give you an answer.
NI sells the 8840 with 4 different OSes.
Windows 7 (64-bit)
Windows 10 (64-bit)
NI Realtime (Pharlap 32-bit)
NI Realtime Linux (64-bit)
So depending how your DLL was compiled it may or may not work on your controller. If it is Window 7 and 10 this should be a fairly easy thing. Just compile your DLL as 64-bit DLL and in the case of Windows 7 make sure you have installed the Distributable Microsoft C Runtime Library for your Visual Studio version.
For Pharlap things get trickier but unless you use a LabVIEW version before 2021, this is not supported by LabVIEW anyhow.
For NI Realtime Linux, your DLL is just a useless binary file no matter how you change the project settings in your Visual Studio project.
VS 2022 is not supported for Pharlap deployment of DLLs. The latest version NI supports is VS 2010. Pharlap had sent out a notice to all users around that time that they are discontinuing the Pharlap ETS product as of around 2013. From that point on there was pretty much no sense in investing any more efforts into the Pharlap platform other than what was needed to keep it working. And with VS 2010 it was definitely enough to keep it working for NI.
There is absolutely no way to get DLLs compiled in later VS versions so that they can be used on Pharlap ETS.
VS2016 and later requires an msvcr14.dll. As you can not install the standard Microsoft version (it wants to hook into Windows 7 and newer APIs specifically that simply do not exist on Pharlap ETS) and there is no NI ported version for Pharlap ETS of that runtime, it simply can't work.
Did you install the "Microsoft Visual Studio 2010 Runtime Support" from within NI-MAX to that target? Just copying some msvcr10.dll over manually is almost certainly not the right thing to do.
Also that Call Library Node really can't do anything with an FTP path. This path needs to be local to he system you want to run this VI and the VI needs to be in a LabVIEW project and under the target for that system.
