Building software for NI Linux RT

[Yosoydodo]

BradM

Yes there is a configure script (I mentionned it in a previous post), but it is highly configurable. The web page details all the necessary steps for the installation http://math-atlas.sourceforge.net/atlas_install/. I have just used the default configuration for the compilation (I didnt have time to do more). ATLAS is a highly spread library far to be exotic and used in a huge variety of comercial and free softwares (like Matlab or Matematica). Just have a look in it wikipedia page http://en.wikipedia.org/wiki/Automatically_Tuned_Linear_Algebra_Software. With no doubts, having this library incorporated in the compacRio will boost the possibilities of the device. 

[BradM]

Yosoydodo,

I'm sure it'd be useful for academic purposes, but there are many applications of this hardware and software that would not use this at all. Having the software that will meet all needs on the target is an impossible task, but having the means to get that software on the hardware for the sufficiently motivated user, that's where the power really comes from.

[Robinswiss]

I'm currently trying to compile LUA for a cRIO-9067. Installing all the opkg packages worked ok and compiling the source on the cRIO starts ok until the end where I get the following error:

...

gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_2 -DLUA_USE_LINUX    -c -o lua.o lua.c

gcc -std=gnu99 -o lua   lua.o liblua.a -lm -Wl,-E -ldl -lreadline

/usr/lib/gcc/arm-nilrt-linux-gnueabi/4.8.2/../../../../arm-nilrt-linux-gnueabi/bin/ld: cannot find crtbegin.o: No such file or directory

/usr/lib/gcc/arm-nilrt-linux-gnueabi/4.8.2/../../../../arm-nilrt-linux-gnueabi/bin/ld: cannot find -lgcc

collect2: error: ld returned 1 exit status

Makefile:63: recipe for target 'lua' failed

make[2]: *** [lua] Error 1

make[2]: Leaving directory '/home/admin/lua-5.3.2/src'

Makefile:110: recipe for target 'linux' failed

make[1]: *** [linux] Error 2

make[1]: Leaving directory '/home/admin/lua-5.3.2/src'

Makefile:55: recipe for target 'linux' failed

make: *** [linux] Error 2

Any idea what the cause or solution could be ?

[BradM]

Robinswiss, welcome!

So, let's start at the start. What version of the NI Linux RT image are you using (and therefore, the feeds that opkg points to).

More generally, are you able to find the file that's being complained about? Using a command something like

find /usr -name "crt*"

[gratian.crisan]

Robinswiss,

If you've installed gcc by running 'opkg install gcc' you might be missing some required dependencies. 'crtbegin.o' is part of the 'libgcc-s-dev' package. One way to make sure you have all the dependencies is to install the 'packagegroup-core-buildessential' package instead.

i.e.

opkg update

opkg install packagegroup-core-buildessential

[gratian.crisan]

Robinswiss,

I forgot to mention in my previous post that LUA version 5.2.2 is available in the 2015 feeds so if you are in a position to upgrade to the 2015 stack and that LUA version works for you then you can skip the whole compile from source problem.

[Robinswiss]

gratian.crisan,

yes installing the "packagegroup-core-buildessential" solved the problem. 

I actually went back to the prestine NI Linux Stack(2015) and did the following:

opkg update

opkg install packagegroup-core-buildessential

opkg install libreadline-dev

This installed all the components needed to compile LUA. It installed more than was realy needed, but it worked to get the compiled version.

My current version is: NI Linux Real-Time ARMv7-A 3.14.40-rt37-ni-3.0.0f2

Thanks about the tip on the latest 2015SP1 feeds. I had checked on the 2015 version when I started with LUA on the cRIO and it was not there. So it's great that it is included in the 2015SP1. I'll give it a try in the next few days.

That makes using LUA even simpler

Here is the result. I Installed  2015SP1 and now have: NI Linux Real-Time ARMv7-A 3.14.46-rt46-ni-3.5.0f0

Doing the following will install LUA without problems:

opkg update

opkg install lua

Message was edited by: Robinswiss added results with the use of 2015SP1

[gangerry]

Recently I am trying to compile and install python3.6 from source code on cRIO-9037(LV 2017), and encountered similar problem in this topic. My procedures are as below:

1. install the compilation tools on cRIO-9037 with 'opkg install packagegroup-core-buildessential'.

2. copy python3.6 source code to cRIO-9037.

3. decompress the source code and enter the source code directory.

4. ./configure

5. make

6. make install

The first 5 steps are smooth, but problems showed in the last step (make install) as below:

ValueError: unsupported hash type sha3_224
ERROR:root:code for hash sha3_256 was not found.
Traceback (most recent call last):
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 243, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 113, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha3_256
ERROR:root:code for hash sha3_384 was not found.
Traceback (most recent call last):
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 243, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 113, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha3_384
ERROR:root:code for hash sha3_512 was not found.
Traceback (most recent call last):
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 243, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 113, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha3_512
ERROR:root:code for hash shake_128 was not found.
Traceback (most recent call last):
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 243, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 113, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type shake_128
ERROR:root:code for hash shake_256 was not found.
Traceback (most recent call last):
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 243, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "/home/lvuser/Python-3.6.2/Lib/hashlib.py", line 113, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type shake_256
Traceback (most recent call last):
File "/home/lvuser/Python-3.6.2/Lib/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/home/lvuser/Python-3.6.2/Lib/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/lvuser/Python-3.6.2/Lib/ensurepip/__main__.py", line 4, in <module>
ensurepip._main()
File "/home/lvuser/Python-3.6.2/Lib/ensurepip/__init__.py", line 189, in _main
default_pip=args.default_pip,
File "/home/lvuser/Python-3.6.2/Lib/ensurepip/__init__.py", line 102, in bootstrap
_run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
File "/home/lvuser/Python-3.6.2/Lib/ensurepip/__init__.py", line 27, in _run_pip
import pip
zipimport.ZipImportError: can't decompress data; zlib not available
Makefile:1067: recipe for target 'install' failed
make: *** [install] Error 1

Does anyone can help me on this issue?

[BradM]

Any particular reason that you need 3.6 over the python 3.5 that's available in the 2017 feeds?

It seems that the installation process is either using a different version of python that is resident on the system (possibly installed through buildessential?) or it is having a difficult time finding the python that was just built for use during installation of that selfsame python.

I'd recommend looking at the makefile to see where it defines the install make target to examine the commands that are failing and/or doing an online search for something along the lines of "python 3 install "ERROR:root:code for hash sha3_224 was not found"" to try to find others who've run into this issue and if they have details on how to fix the installation issue (e.g. doing something along the lines of adjusting environment variables to allow the installation to find your new version of python and that new version of python to find the modules that you just built).

[HasbunWoodEngineering]

Hello gangerry,

I am trying to build Python 3.7 in a myRIO device with NI myRIO 17.0 and I am getting the same error regarding zlib during make install:

Traceback (most recent call last):
File "/home/admin/Python-3.7.0/Lib/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/home/admin/Python-3.7.0/Lib/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/admin/Python-3.7.0/Lib/ensurepip/__main__.py", line 5, in <module>
sys.exit(ensurepip._main())
File "/home/admin/Python-3.7.0/Lib/ensurepip/__init__.py", line 204, in _main
default_pip=args.default_pip,
File "/home/admin/Python-3.7.0/Lib/ensurepip/__init__.py", line 117, in _bootstrap
return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
File "/home/admin/Python-3.7.0/Lib/ensurepip/__init__.py", line 27, in _run_pip
import pip._internal
zipimport.ZipImportError: can't decompress data; zlib not available
Makefile:1122: recipe for target 'install' failed
make: *** [install] Error 1

Were you able to solve your problem?

Thanks in advance,

Juan