GNU C & C++ Compilers for x64 Linux (Windows Host) installation and running issue

[himre]

There is an error when installing NILRT on Windows following this page. GNU C & C++ Compilers for x64 Linux (Windows Host) from Package manager, installs all in C:\Program Files (x86)\National Instruments\Eclipse\17.0 directory of host.  
I've installed JDK and updated the eclipse.ini configuration file:

openFile
--launcher.appendVmargs
-vm
C:\Program Files\Java\jdk-XX\bin\javaw.exe
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Xms256m
-Xmx1024m
-XX:MaxPermSize=256m

 
However, I get following error:

Which is for what I can see architecture conflict. I installed 64bit Java but apparently Eclipse that comes with NI Compile Toolchain is 32bit. Is it true?
What could be the solution to use GNU C & C++ Compilers for x64 Linux for cross compiling in Windows? Should I install Eclipse again in the NI directory?

[ZYOng]

Linux dislikes file paths with spaces.

Try installing it to the C:\ directly.

[rolfk]

Aside from possible path issues, the Eclipse toolchain is very old and outdated. This is from 2017, which is an eon old in computer terms. Unless you need to support old LabVIEW versions before 2019 or so, you really should use the Visual Studio Code based cross compile toolchain instead.

Eclipse was a nice idea but it is notoriously hard to configure right if you do not just want to do Java development. And yes, back in 2017 it was still often distributed as 32-bit version. Only Eclipse Photon did abandon support for Windows 32 bit installations.

https://nilrt-docs.ni.com/

Downloads:

https://nilrt-docs.ni.com/cross_compile/config_dev_system.html

[himre]

Thank you very much for the reply.

Not sure how can I do that, because installing either by the executable installer in here or through NI Package Manager it does it automatically for the whole package.

[himre]

Thanks a lot for the reply.

Any cross-compiler is good as long as it is supported by NI. I just found that from documents and tried it, but now will switch to NILRT as you suggest.
Just to be sure; are you referring to this: https://www.ni.com/en/support/downloads/software-products/download.gnu-c---c---compile-tools-x64.htm... right?

And that is a GNU compiler, so meaning that even if I have build some library in other Linux machine with gcc and g++, it should be working in RT target (say it is 64bit shared library with a not old gcc and g++ version), is this assumption correct?

Thanks in advance. 

[rolfk]

---

@himre wrote:

And that is a GNU compiler, so meaning that even if I have build some library in other Linux machine with gcc and g++, it should be working in RT target (say it is 64bit shared library with a not old gcc and g++ version), is this assumption correct?

---

GCC is always a bit difficult to make such statements for sure. They tend to change things for no other reason but because they can. So versions, ABIs and the like can change at any time, for any reason simply because someone felt it was a good idea. The NI Linux system is based on a embedded Linux platform (Yocto?) with some lag, since they need to upgrade from time to time from upstream. That embedded platform tracks the standard Linux kernel as upstream with some more lag. That all makes things not easier.

[himre]

Thanks Rolf, so at this point the safest approach is to use the NI Compiler toolchain.

[rolfk · Accepted solution]

---

@himre wrote:

Thanks Rolf, so at this point the safest approach is to use the NI Compiler toolchain.

---

Well, you answered your own question in the way you asked.

Safest? Yes definitely! You may be able to create shared libraries in your favorite Ubuntu, Redhat or whatever desktop installation if you make sure they create amd64/x64 code and use just the right compile switches when invoking gcc. But only for the cRIO 903x, 904x and 905x , and the Intel based sbRIO.

The ARM eabi used on the NI Zync platform (cRIO 906x, sbRIO 9507, 9527, 9537, and 9561 as well as the myRIO 19xx) is rather specific and other compiler toolchains are very unlikely to create the correct format out of the box, although they may be possible to get whipped into submission sometimes. But if you are not a gcc hacker and low level crack, the safest is definitely to go with the recommended toolchain.