SQLite for OpenG

[igorbounov]

4 hours ago, drjdpowell said:

Go get VIPM from JKI directly.

...if one has a copy of the sqlite3.so shared library installed in the right place. 

I've got VIPM from JKI, there are also installation instructions available, but there is not said how this VIPM could be run in an already existing LV 2018. But all this VIPM things are useless if SQLite Addon is unusable under Linux.

sqlite3.so is available in any Linux distribution (and in any Android, almost in every SmartTV, smart-refrigerator...).

[igorbounov]

In Fedora (and hence, in RedHat and CentOS, too) sqlite is located in:

/usr/lib64/libsqlite3.so.0

/usr/lib/libsqlite3.so.0

Those are stable links to actual libraries for 64- and 32-bit library builds.

[Rolf Kalbermatter]

1 hour ago, igorbounov said:

In Fedora (and hence, in RedHat and CentOS, too) sqlite is located in:

/usr/lib64/libsqlite3.so.0

/usr/lib/libsqlite3.so.0

Those are stable links to actual libraries for 64- and 32-bit library builds.

Things are not that simple! LabVIEW on Linux RT comes in two flavors. For the ARM based targets and the x86 based targets.

The 64-bit Fedora/Centos/Redhat binaries MIGHT work for the x86 based targets, but in my work with these I always compiled shared libraries from the source for these targets.

For the ARM based targets you will almost certainly need to recompile them from source. Just because it says ARM does by far not mean that it is all the same although many of the SmartTV and similar hardware are probably running on some ARM CPU.

The NI Linux RT used on the ARM targets needs binaries compiled specifically for the ARM CortexA implementation and should be compiled with softfp enabled. Otherwise floating point performance will be not very good.

There are basically two ways to get a valid binary for the ARM cRIOs (works also for the x86_64 based cRIOs too):

1) Either cross compilation with a GNU C cross compiler that is prepared for the specific target such as explained here: http://www.ni.com/tutorial/14625/en/

2) or installing the C development tools on your actual target using the opgk feeds from NI and compiling the sources there on the command line. This is however only for those who are not faint at heart and know about how configure, make, make install works. 😀 And you shouldn't be afraid to tweak the generated Makefile a little to fit your system exactly.

 

[igorbounov]

Why RT or ARM targets?

No, it's all quite simple. I've installed VIPM, it installed this drjdpowell SQLite Library, it seems that all work marvelous!

Thanks again for this great library!

I've tested two sqlite examples - they work without problem!

The only inconvenience - the search in Example tab cannot find "sqlite", I've found examples in a directory search of Examples window.

[Curr93]

Please explain me about ODBC driver for your SQLite Library, in other words, whether such a driver is needed or not?

[Mads]

5 hours ago, Curr93 said:

Please explain me about ODBC driver for your SQLite Library, in other words, whether such a driver is needed or not?

The library operates directly on the database file, no ODBC.

[Curr93]

2 hours ago, Mads said:

The library operates directly on the database file, no ODBC.

Thank you very much Mads! This is very good option when ODBC driver no needed. Would you be so kind to tell me about compatibility SQLite Library with LV modern versions for example LV2014 and above? 

What do you think about "SQLite is nifty too but not so suitable for a server-side database with multiple concurrent remote users"?

Edited December 16, 2020 by Curr93
one more question

[Mads]

2 hours ago, Curr93 said:

Thank you very much Mads! This is very good option when ODBC driver no needed. Would you be so kind to tell me about compatibility SQLite Library with LV modern versions for example LV2014 and above? 

What do you think about "SQLite is nifty too but not so suitable for a server-side database with multiple concurrent remote users"?

According to VI Package Manager the library is compatible with LabVIEW 2013 and onwards...SQLite can support multiple users, but it locks the whole database when writing, so if you have lots of concurrent writes it is not the database you want (usually the time the database is locked is a few milliseconds - so for most uses this does not matter).

[Antoine Chalons]

I'm not sure where the best place was to post this information, so the original post is on the NI forums (wider audience I think)

To make it short, the dll included in the SQLite package is version 3.32, but the latest you can install via opkg on NI Linux RT target is 3.22

The consequence is that some features will not work on Linux RT, it is possible to get the source code from SQLite.org and compile an so file from 3.34, check the link above.

 

Anyone knows if it's possible to include that in the SQLite package in order to deploy the library to Linux RT target via MAX or something?

I know @Rolf Kalbermatter did something similar for the LVZip package to deploy the library to Linux RT...

[Antoine Chalons]

If you want NI to update the SQLite version available via opkg, vote here.

[Rolf Kalbermatter]

50 minutes ago, Antoine Chalons said:

I know @Rolf Kalbermatter did something similar for the LVZip package to deploy the library to Linux RT...

The LabVIEW deployment of VIs to a target does not copy over shared libraries and other binary objects to the target system.

(Well it did for Pharlap targets but that was not always desirable. Originally Pharlap's Win32 implementation was fairly close to the Win NT4 and Win2000 API and many DLLs compiled for Windows NT or 2000 would work without change on Pharlap too. But with newer Windows versions diverting more and more from the limited Win32 support provided by Pharlap ETS and unless you went to really great lengths, including NOT using newer Visual Studio versions to compile your DLL, you could forget that a DLL would work on Pharlap.

In addition LabVIEW on Windows has no notion of Unix shared libraries and so they simply removed that automatic deployment of such binary files to a target, even if that file would be present in the source tree. The possible implications and special requirements of how to install VxWorks OUTs and Unix SOs on a target system were simply to involved and prone to problems.)

So to get such files properly put on the target system you need a separate installer. NI uses for their software libraries the so called CDF (Component Description Format) (not sure if they developed that themselves or snatched it from somewhere 😀). For the LV ZIP Toolkit I "reverse engineered" the NI CDF file structure to create my own CDF file for my lvzlib shared library. When you place that and the according shared library/ies into a folder inside <ProgramFilesx86>\National Instruments\Shared\RT Images, NI Max will see this cdf file and offer to install the package to the remote target if the supported targets in the CDF file are compatible with the target for which you selected the Install menu.

This works but is made extra complicated by the fact that a normal user has no write access to the Shared directory tree. So if you add these files to your VI package, you must require VIPM to be started as administrator. Extra complication is that VIPM does not offer the "Shared/RT Images" path as a target option, so you would need to do all kind of trickery with relative paths, to get it installed there.

I instead used InnoSetup to create a setup program containing those files and configured to require administrator elevation on startup. I then start this setup program from the PostInstall step in the package.

But NI has slated CDF to be discontinued sometimes in the near future and to require NIPM packages instead to be used.

 

Edited January 19, 2021 by Rolf Kalbermatter

[Antoine Chalons]

Just out of curiosity, how much work was it to reverse engineer the CDF and create the installer in order to be able to install the lvzip library on a RT target from MAX?

 

For the SQLite3 library it might be made more complicated by external dependencies of the libsqlite3.so...

But NI is planning to release a new RT Linux with support for SQLite 3.31.1, see here.

[Rolf Kalbermatter]

2 hours ago, Antoine Chalons said:

Just out of curiosity, how much work was it to reverse engineer the CDF and create the installer in order to be able to install the lvzip library on a RT target from MAX?

 

For the SQLite3 library it might be made more complicated by external dependencies of the libsqlite3.so...

But NI is planning to release a new RT Linux with support for SQLite 3.31.1, see here.

Well, the reverse engineering was quite some work as I had to view many different existing CDF files and deduce the functionality of them. But creating a new one for the sqllite library itself should be straight forward by taking the one for lvzip and changing the relevant strings in the CDF file. Only thing besides that is that you need to generate also your own GUID for your package as that is how Max identifies each package. But there are many online GUID generators that can do that for you, and the chance that that will conflict with any GUID already in use is pretty much non-existent. Depending if you also want to support sqllite support for Pharlap and VxWorks you would have to either leave those sections in the CDF file or remove them.

You can also handle dependencies and depending on what libraries you need they may actually exist as packages from NI already. Adding such dependencies to your CDF file is basically adding the relevant GUID from that other CDF file and version number to your own CDF file. Works quite well but if NI doesn't have the package available already, things can get more complicated. You either have to create an additional CDF file for each such package or you could possibly add the additional precompiled modules to the initial CDF file. A CDF file can reference multiple files per target, so it's possible but can get dirty quickly.

Edited January 19, 2021 by Rolf Kalbermatter