Hobbyist Toolkit

Showing results for 
Search instead for 
Did you mean: 

Possible raspberry pi target install error - too many bits folders

I noticed that my .h and .so files appear to not be in the proper location for the chroot install of labview on my raspberry pi 4B.  Is anyone interested in this?  I am not sure who to escalate this to.  I am happy to provide any information needed to diagnosis this.  I remember that my target install was not "clean" in that it said the install was finished with some errors, however I was able to run some basic LINX blink examples.  Here is a screenshot below, and I could have gone farther deep into the bits...bits...bits... folder structure. 



0 Kudos
Message 1 of 10

I also noticed that with version 20.0.0-4 of linx target on raspberry pi 4 B, that these are the only header files that I have in labview chroot folders that gcc searches for header files.  Does this seem sparce? Should it search other folders?  It appears to look for three other directories, but one is a duplicate and is ignored and two others cannot be found.  I think it is missing a lot of files, which could explain why gcc cannot compile a *.c file with a standard header file like stdio.h while in labview chroot.





0 Kudos
Message 2 of 10

Ok, so now I installed 14.1-11 and fixed the services location, then went into chroot and also installed with the following command: "opkg install packagegroup-core-buildessential" which results in a lot more files shown below!




0 Kudos
Message 3 of 10

Seems that the upstream providers repackeged the opkg packages and packagegroup-core-buildessential doesn't contain the whole gcc development stuff anymore.


Since packagegroup-core-buildessential is basically just a meta package that lists many different sub packages to install, something in the gcc-devel packages seems to have changed.


The LabVIEW Makerhub tutorial is specific to the LabVIEW chroot environment (and according opkg repository) for the then current LabVIEW 2014 environment, That's about 6 years which is a very long time for Linux development standards to not change something like this 😀.


Now I have to admit that I'm far from an opkg specialist and that tool has evaded me in the past several times in how to determine what package I need to install for a specific support library. Its build in search capability is very limited and many package descriptions show little more info than the package name itself and some generic info. Usually some involved Google-foo was the only way to find out.


The opkg provided info for the differet packages felt at times like those UI manuals that have a description for a button labeled "Open" saying "Opens a file for processing". Great, I wouldn't have guessed that? But what sort of file, what kind of processing and so on?


Do you have a package "gcc-devel" in your opgk list?

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 10

I don't see anything like "gcc-devel" when I enter in the following command:


opkg info gcc-devel


However I get some more search results when I enter in the following command:


opkg info gcc.....


I see both of these have some interesting dev header/lib type descriptors:


libgcc-s-dev: Description: GNU cc and gcc C compilers - Development files GNU cc and gcc C
compilers. This package contains symbolic links, header files, and
related items necessary for software development.
gcc-dev: Description: GNU cc and gcc C compilers - Development files GNU cc and gcc C
compilers. This package contains symbolic links, header files, and
related items necessary for software development.


It should not hurt to install them to see what header and lib files get added, so I will try now.

0 Kudos
Message 5 of 10

This is the info that I get for packagegroup-core-buildessential.... appears maybe gcc no longer carries all the header and lib files?


root@raspberrypi:/home/pi# opkg info packagegroup-core-buildessential
Package: packagegroup-core-buildessential
Version: 1.0-r0
Depends: cpp-symlinks, gcc, binutils-symlinks, g++-symlinks, pkgconfig, gettext, automake, libstdc++, g++, libtool, libstdc++-dev, cpp, gcc-symlinks, autoconf, make, binutils
Status: unknown ok not-installed
Section: base
Architecture: all
Maintainer: Poky <poky@yoctoproject.org>
MD5Sum: ceeb92c1ef44bd8de452775006c8dd50
Size: 706
Filename: packagegroup-core-buildessential_1.0-r0_all.ipk
Source: None
Description: Essential build dependencies Essential build dependencies.

0 Kudos
Message 6 of 10

root@raspberrypi:/home/pi# opkg install libgcc-s-dev

Collected errors:
* Solver encountered 1 problem(s):
* Problem 1/1:
* - package libgcc-s-dev-4.9.2-r0.armv7a-vfp requires libgcc1 = 4.9.2-r0, but none of the providers can be installed
* Solution 1:
* - allow downgrade of liblinxdevice-19.0-git0+0284962640-r0.armv7a-vfp to liblinxdevice-2.1-git0+b25091394e-r0.armv7a-vfp

* - allow downgrade of lv-web-support-20.0.0-r0.armv7a-vfp to lv-web-support-14.0.0-r0.armv7a-vfp

* - allow downgrade of lv-appweb-support-20.0.0-r0.armv7a-vfp to lv-appweb-support-14.1.0-r0.armv7a-vfp

* - allow downgrade of labview-20.0.0-r0.armv7a-vfp to labview-14.1.0-r0.armv7a-vfp

* - allow downgrade of visa-20.0.0-r0.armv7a-vfp to visa-15.5.0-r0.armv7a-vfp

* - allow downgrade of opkg-1:0.4.0-r0.armv7a-vfp to opkg-1:0.2.4-r0.armv7a-vfp

* Solution 2:
* - do not ask to install a package providing libgcc-s-dev









root@raspberrypi:/home/pi# opkg install gcc-dev
Installing libgmp10 (6.0.0) on root
Downloading http://feeds.labviewmakerhub.com/armv7a/ipk/armv7a-vfp/libgmp10_6.0.0-r0_armv7a-vfp.ipk.
Installing libmpfr4 (3.1.2) on root
Downloading http://feeds.labviewmakerhub.com/armv7a/ipk/armv7a-vfp/libmpfr4_3.1.2-r0_armv7a-vfp.ipk.
Installing libmpc3 (1.0.2) on root
Downloading http://feeds.labviewmakerhub.com/armv7a/ipk/armv7a-vfp/libmpc3_1.0.2-r0_armv7a-vfp.ipk.
Installing gcc (4.9.2) on root
Downloading http://feeds.labviewmakerhub.com/armv7a/ipk/armv7a-vfp/gcc_4.9.2-r0_armv7a-vfp.ipk.
Installing gcc-dev (4.9.2) on root
Downloading http://feeds.labviewmakerhub.com/armv7a/ipk/armv7a-vfp/gcc-dev_4.9.2-r0_armv7a-vfp.ipk.
Configuring libgmp10.
Configuring libmpfr4.
Configuring libmpc3.
Configuring gcc.
Configuring gcc-dev.






gcc-dev appears to have worked!






before: all folders were non-existent or empty except for this:


pi@raspberrypi:/srv/chroot/labview/usr/lib $ ls
libarchive.so.13 liblinxdevice.so librtpi.so.0.0.0
libarchive.so.13.3.3 liblzma.so.5 libsolv.so.1
libbz2.so.1 liblzma.so.5.2.4 libstdc++.so.6
libbz2.so.1.0.6 liblzo2.so.2 libstdc++.so.6.0.25
libkmod.so.2 liblzo2.so.2.0.0 libxml2.so.2
libkmod.so.2.3.4 libopkg.so.1 libxml2.so.2.9.8
liblinxdevice_bbb.so libopkg.so.1.0.0 opkg
liblinxdevice_rpi2.so librtpi.so.0




now after gcc-dev install, here is the new contect:


pi@raspberrypi:/srv/chroot/labview/usr/include $ ls



pi@raspberrypi:/srv/chroot/labview/usr/lib $ ls
gcc liblinxdevice_rpi2.so libopkg.so.1
libarchive.so.13 liblinxdevice.so libopkg.so.1.0.0
libarchive.so.13.3.3 liblzma.so.5 librtpi.so.0
libbz2.so.1 liblzma.so.5.2.4 librtpi.so.0.0.0
libbz2.so.1.0.6 liblzo2.so.2 libsolv.so.1
libgmp.so.10 liblzo2.so.2.0.0 libstdc++.so.6
libgmp.so.10.2.0 libmpc.so.3 libstdc++.so.6.0.25
libkmod.so.2 libmpc.so.3.0.0 libxml2.so.2
libkmod.so.2.3.4 libmpfr.so.4 libxml2.so.2.9.8
liblinxdevice_bbb.so libmpfr.so.4.1.2 opkg


pi@raspberrypi:/srv/chroot/labview/usr/lib/gcc/arm-poky-linux-gnueabi/4.9.2/include $ ls
arm_acle.h mmintrin.h stdbool.h stdint.h varargs.h
arm_neon.h stdalign.h stddef.h stdnoreturn.h
float.h stdarg.h stdfix.h unwind-arm-common.h
iso646.h stdatomic.h stdint-gcc.h unwind.h


pi@raspberrypi:/srv/chroot/labview/usr/lib/gcc/arm-poky-linux-gnueabi/4.9.2/include-fixed $ ls
libv4l1-videodev.h limits.h README X11
libv4lconvert.h openssl syslimits.h




maybe that is not the solution.... 😞



0 Kudos
Message 7 of 10

Checkout above lists: target version 20.0.0-4 has less lib/header files than version 14.1-11 by using the same opkg commands. Weird right? Also it appears the downloads happen from makerhub.... maybe the files given to rpi depend on the target version?


Are any of the LINX developers on these forums that can comment on what is happening?  Maybe the dev package is version specific?

0 Kudos
Message 8 of 10

@bbelley wrote:


Are any of the LINX developers on these forums that can comment on what is happening?  Maybe the dev package is version specific?

Absolutely! The different LabVIEW runtimes work with different Linx kernel versions. This also requires often a new set of support libraries compiled against the according kernel headers.


So if you install a LabVIEW chroot 2014 image, it should use a different kernel version than the LabVIEW chroot 2020 image. Basically the chroot image is its own Linux VM inside your Raspberry Pi. This is necessary for a few reasons. One is that while Raspbian is compiled with arm-eabi-hard support (since the Broadcom chip contains the necessary NEON hardware support) the NI Linux RT system is compiled with arm-eabi-softfp which emulates a FPU in software. Since this is part of the ABI (Application Binary Interface) specification you can not mix and match softfp and hardfp binary modules. That would completely mess up the softfp registers the emulation layer uses and give you very weird floating point results if it wouldn't crash right away. See here for more details about ARM FPU architectures. This is since the ARM CPU support in the Xilinx Zync chip on the NI RIO targets running Linux for ARM, does not provide a NEON or even its predecessor VFP hardware unit to support hardware FPU implementation. This is a valid choice by Xilinx since the VFP and/or NEON support is an optional feature of the ARMv7a architecture.


So rather than having to recompile and test all the LabVIEW modules and drivers with "arm-eabi-hard" for support of Raspberry Pi and Beaglebone Black, which NI would not likely do as it adds a complete new build target to the already rather complex build setup of LabVIEW and all the various drivers, it was a lot easier to create a Linux RT build for the softfp emulation and provide a chroot image that can be run on any Linux for ARM host. There still are dependencies of the LabVIEW versions and more so of the various drivers to Linux kernel versions, so you can't just install the chroot environment for LabVIEW 2014 and hope to get it running with the LabVIEW 2020 runtime. In fact part of the chroot environment that you install with the Linx Device Configuration wizard also contains the according LabVIEW runtime components that you would not have any legal rights to install yourself on a Linux target without a specific license agreement with NI.


Rolf Kalbermatter
Averna BV
Message 9 of 10

Cool thanks for the info!


I hope the information above that I provided is helpful in troubleshooting this behavior.

0 Kudos
Message 10 of 10