Hobbyist Toolkit

Showing results for 
Search instead for 
Did you mean: 

Re building the liblinxdevice_rpi2.so shared library.

Go to solution

Has anyone managed to rebuild the liblinxdevice_rpi2.so then successfully use it without making any changes to it?


I have a simple test program running labview flashing an LED which works fine straight out od the box.

I want to modify the SPI to use both the spidev0.0 and spidev0.1 devices plus a few more as this apperas to have been commented on a few times in the past as a restriction. I have modified the PI spi device driver to support sub addressing using additional GPIO pins for address lines and hence give me separate spi devices spidev0.0 through to spidev0.31, yes 32 separate resource locked SPI chip selects, works like a charm from 'C' code test applications but now I want it to work on LabView.


I have taken the latest source fileset and run make using the PI as the development environment and rebuilt the shared library as is without any changes to check it is building correctly.


1) First thing I notice is the built library comes out at about 700K which is over 10 times the size of the one supplied in the target installation package which is only 54K in size, very strainge.


2) I then copied the new file over to replace the one located in the /srv/chroot/labview/usr/lib directory, then did a reboot of the pi to ensure the shared library would be reloaded.


3) When I try to run the labview test program alI I get a deplovment error 


Deploying LMH-LINX.lvlib:Local IO.lvlib:Load Device Channels.viLMH-LINX.lvlib:Local IO.lvlib:Load Device Channels.vi loaded with errors on the target and was closed.
Deployment completed with errors


This error usually indicated there is no shared library or something in the library is broken.


So I have changed no source code, rebuilt the shared libraries and reloaded but I can't get past this error.


Is there a way of getting Labview to give me more detail of the error, or better still has anyone got the answer.


Thanks Mark




0 Kudos
Message 1 of 6

Hi. Sounds like the struggle I had building a .so lately.

First, did you compile it when inside the lv schroot? You have to. See the PDF here: https://www.labviewmakerhub.com/forums/viewtopic.php?f=12&t=1864


However, I bet you run into same issues as posted later in the same thread - compiler fails. I tried a lot to make it build (using the lvrt20-schroot), but never succeeded. Eventually - I manually installed the lvrt-schroot from 2016, and there I managed to compile it. I then used that .so with lvrt20-schroot no problem. (to manually install lvrt-schroot, I used guide in this post: 




A lot of hassel - yes, so it any LINX developers are reading this - I hope you could look into current lvrt20-schroot verison and figure out why it fails to compile .so (thanks)! 


Hope this helps you, 




Message 2 of 6

As to your point 2) the makefiles as on github use compile switches that create a debug build of the compiled products.


To change that you need to remove the -g option from the relevant make rules (it's the last thing on the correspending line.

Then to make it compile a comparable object module to what is distributed with the Linx Toolkit you can add an optimization flag instead.


Personaly I added a line




somewhere in the beginning of the makefile. This variable is used in all compile commands later on and will then set additional options for the compiler commands.


With this you definitely should get a shared library with comparable size.

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 6
Accepted by topic author aelmicro

Thanks for all your comments😀


I have successfully built the library and added some modifications to the SPI so that you can access both of the SPI0 chips selects of /dev/spidev0.0 and 0.1, and also all 3 of the SPI1 chip selects of /dev/spidev1.0, 1.1 & 1.2 giving 5 separate channels.


First up I got it to build by downloading the latest Linix hosted cross compiler for ARM tools from national instruments and installing them on my Linux openSuse virtual machine, as per the instructions. I have also managed to integrate that toolset into my windows hosted VisualGDB running inside VisualStudio, so that I can compile remotley on the Linux VM then debug on the Pi this will mean that I can write libraries and applications that will run inside the labview chroot without compatibility issues.



VisualGDB setup for NI cross compiler to target Raspberry Pi


On VM ensure gcc-c++ tools are installed


Download the GNU Linux host cross compiler for ARM from the no website to your Linux /home/Downloads directory on the virtual machine.


The file name should be something like oecore-x86_64-cortexa9-vfpv3-toolchain-6.0.sh


Change the permissions of the file to executable then run it:


$ ./oecore-x86_64-cortexa9-vfpv3-toolchain-6.0.sh


Change the installation address to /usr/local/ni-linux-arm7, then the toolchain will be installed.


Open Visual Studio from the Windows host.

Add a new project

Select name and folder for the project, then press OK.

On the next screen select “Build the project under Linux over network”

From the Remote computer select an existing remote machine or create a new SSH connection.

From Remote Toolchain select an existing toolset or create a new on by selecting “Specify a Yocto Environment file”

Select the file on the remote at:


Press OK

In the next dialog add a Name, “Ni-Linux-Arm”, then press OK.


During the compilation test ignore the executing of the test file error as its an ARM compiled target trying to run on a x86 machine.


Select the deployment machine as the Raspberry Pi


At the next screen, press Finish.

Select the new project and do a rebuild, all should compile and link OK.


On the Raspberry pi install the gdbserver:

                $ sudo apt-get install gdbserver


Your should now be able to run and debug the test program.



To run with SPI with extra chip selects and channels.




                #define NUM_SPI_CHANS 1                        to            #define NUM_SPI_CHANS 5     


                #define NUM_SPI_CHANS_SPI0  2


In class LinxDevice         

                Remove const from static unsigned char m_SpiChans[NUM_SPI_CHANS]



In Function          LinxRaspberryPi2B::LinxRaspberryPi2B()

Remove const from  unsigned char m_SpiChans[NUM_SPI_CHANS];


Added in LinxRaspberryPi2B() constructor in the SPI initialisation loop to fill array of device path strings.

        char buffer[32];


        if(i < NUM_SPI_CHANS_SPI0)


            sprintf(buffer, "/dev/spidev0.%d", i);

            m_SpiPaths[i] = buffer;




            sprintf(buffer, "/dev/spidev1.%d", i - NUM_SPI_CHANS_SPI0);

            m_SpiPaths[i] = buffer;



        SpiChans[i] = i;                         



In class LinxDevice         

                Remove const from unsigned char* SpiChans;



I have attached the files for the liblinxdevice for your enjoyment.


All the best





Message 4 of 6

You forgot to mention how to enable the extra /dev/spidev1.x devices in your Raspberry Pi. By default they are not enabled on a Raspberry Pi (and can't be from raspi-config).


To also enable the auxiliary SPI device (three slave selects) add the line

 dtoverlay=spi1-3cs to /boot/config.txt.


Rolf Kalbermatter
My Blog
Message 5 of 6

Hi Rolf,


Thanks for mentioning that oversite.



0 Kudos
Message 6 of 6