Labview runtime engine [SOLVED]

sportscliche · 2010-12-27 11:57:10

Hi, I'm a new Arch user having migrated from Ubuntu a few weeks ago. I've been stuck for several days trying to get the National Instruments Labview runtime engine installed. It is an easy process on Ubuntu so it must be possible with Arch. I'd prefer not to operate outside of pacman (ie. installing with rpm or dpkg) based on what I've read in the forums.

The Labview runtime engine is a free download from National Instruments and allows programs that are generated by the Labview developer package (expensive) to be run on any box without having the licensed Labview software installed. This is handled with two .rpm files that one downloads from the NI website after registering there. You must download the .rpm files appropriate for the version of Labview that generated your executable. (Note that executables generated by Windows Labview and Linux Labview are not interchangeable) For reference, those files can be found here:

http://joule.ni.com/nidu/cds/view/p/id/1103/lang/en

For Ubuntu, I converted the .rpm files to .deb using alien and installed them with dpkg. The Labview executables can then be run by opening them in the file manager. As a first step in Arch, I unbundled the .rpm files using rpmextract and found that they are just a bunch of library files placed in usr sub-directories. I then wrote the following naive PKGBUILD followed by makepkg -s.

pkgname=lvtest
pkgver=1
pkgrel=1
arch=('i686' 'x86_64')
license=('GPL')
makedepends=('rpmextract')
source=("labview86-rte-8.6.0-1.i386.rpm" 
"labview-rte-aal-1.1-1.i386.rpm")

md5sums=('37b43da794fd9c61d0c5e3c9cfa56628'
         'a2110e5b5677351095bd93e5b1aa5bea')

build() {
    cd ${srcdir}
    rpmextract.sh labview-rte-aal-1.1-1.i386.rpm
    rpmextract.sh labview86-rte-8.6.0-1.i386.rpm
    cp -ra ${srcdir}/usr $pkgdir/
}

This generates a pkg.tar.xz that I install with pacman -U. My problem is that the Labview executables are not being recognized, ie. I don't know how to open them. I suspect this has something to do with permissions or perhaps linking that I sometimes see in other PKGBUILD files, but I don't know how to proceed. I am brand new at this, but have spent a lot of time searching the wiki and forums looking for hints and guidance.

Last edited by sportscliche (2011-01-02 23:58:49)

Xyne · 2010-12-27 13:13:41

What is the output of "pacman -Ql lvtest"?

Most likely you should be using the "install" command to both install the files in the $pkgdir and set their permissions, or some combination of "cp" and "chmod". It is unlikely that you want to dump the contents of $srcdir/usr directly into the root directory. Presumably the executables are not on your path because of this.

The list of files in the package will hopefully make it clear what should be where.

Btw, you should also wrap all variables in double quotation marks, and you should probably remove x86_64 from the arch array, given that the packages are i386. Even if it doesn't affect you, you should start reinforcing good habits from the start.

Last edited by Xyne (2010-12-27 13:14:18)

sportscliche · 2010-12-27 14:12:23

Thanks for the fast reply! Output of pacman -Ql lvtest follows:

lvtest /usr/
lvtest /usr/local/
lvtest /usr/local/lib/
lvtest /usr/local/lib/LabVIEW-8.6/
lvtest /usr/local/lib/LabVIEW-8.6/.data/
lvtest /usr/local/lib/LabVIEW-8.6/.data/Analysis-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/IAK_SHARED-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/LV_RemotePanelConnection.lic
lvtest /usr/local/lib/LabVIEW-8.6/.data/LabVIEW Simulation Module-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/LabVIEW-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/Measure-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/NI-488-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/NI-Reports-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/.data/VISA-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/English/
lvtest /usr/local/lib/LabVIEW-8.6/English/lvapp.rsc
lvtest /usr/local/lib/LabVIEW-8.6/English/vidialogs.rsc
lvtest /usr/local/lib/LabVIEW-8.6/LV86NPlugin.so
lvtest /usr/local/lib/LabVIEW-8.6/copyright.txt
lvtest /usr/local/lib/LabVIEW-8.6/errors/
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/Analysis-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/IAK_SHARED-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/LabVIEW Simulation Module-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/LabVIEW-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/Measure-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/errors/English/NI-Reports-errors.txt
lvtest /usr/local/lib/LabVIEW-8.6/libappweb.so
lvtest /usr/local/lib/LabVIEW-8.6/libappweb.so.2
lvtest /usr/local/lib/LabVIEW-8.6/libappweb.so.2.3.0
lvtest /usr/local/lib/LabVIEW-8.6/liblkdynam.so
lvtest /usr/local/lib/LabVIEW-8.6/liblkdynam.so.5
lvtest /usr/local/lib/LabVIEW-8.6/liblkdynam.so.5.0.0
lvtest /usr/local/lib/LabVIEW-8.6/liblkrealt.so
lvtest /usr/local/lib/LabVIEW-8.6/liblkrealt.so.5
lvtest /usr/local/lib/LabVIEW-8.6/liblkrealt.so.5.0.0
lvtest /usr/local/lib/LabVIEW-8.6/liblksec.so
lvtest /usr/local/lib/LabVIEW-8.6/liblksec.so.5
lvtest /usr/local/lib/LabVIEW-8.6/liblksec.so.5.0.0
lvtest /usr/local/lib/LabVIEW-8.6/liblksock.so
lvtest /usr/local/lib/LabVIEW-8.6/liblksock.so.5
lvtest /usr/local/lib/LabVIEW-8.6/liblksock.so.5.0.0
lvtest /usr/local/lib/LabVIEW-8.6/liblvrt.so.8.6.0
lvtest /usr/local/lib/LabVIEW-8.6/liblvrtdark.so.8.6.0
lvtest /usr/local/lib/LabVIEW-8.6/libnids.so
lvtest /usr/local/lib/LabVIEW-8.6/libnids.so.4
lvtest /usr/local/lib/LabVIEW-8.6/libnids.so.4.5.4
lvtest /usr/local/lib/LabVIEW-8.6/libnitaglv.so
lvtest /usr/local/lib/LabVIEW-8.6/libnitaglv.so.1
lvtest /usr/local/lib/LabVIEW-8.6/libnitaglv.so.1.5.0
lvtest /usr/local/lib/LabVIEW-8.6/libniwebsrv.so.1.0.0
lvtest /usr/local/lib/LabVIEW-8.6/libnixerces.so
lvtest /usr/local/lib/LabVIEW-8.6/libnixerces.so.2
lvtest /usr/local/lib/LabVIEW-8.6/libnixerces.so.2.7.0
lvtest /usr/local/lib/LabVIEW-8.6/linux/
lvtest /usr/local/lib/LabVIEW-8.6/linux/README.libs
lvtest /usr/local/lib/LabVIEW-8.6/linux/libstdc++.so.5
lvtest /usr/local/lib/LabVIEW-8.6/linux/libstdc++.so.5.0.3
lvtest /usr/local/lib/LabVIEW-8.6/lvanlys.so
lvtest /usr/local/lib/LabVIEW-8.6/lvdark
lvtest /usr/local/lib/LabVIEW-8.6/models/
lvtest /usr/local/lib/LabVIEW-8.6/models/arrow.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/attank.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/bowvalve.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/box_inc.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/box_incp.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/boxshadow.3ds
lvtest /usr/local/lib/LabVIEW-8.6/models/frame_i.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/frame_o.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/gauge_f.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/inc.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/knob_d.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/knob_h.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/knob_t.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/meter_f.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/meter_g.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/meter_h.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/pb_d.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/pb_h.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/pb_l.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/pro_bar.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/pro_bar_in.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/rectvalve.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/rocker.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/rockerl.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/rockerr.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/slided.3ds
lvtest /usr/local/lib/LabVIEW-8.6/models/slideh.3ds
lvtest /usr/local/lib/LabVIEW-8.6/models/slider_b.3ds
lvtest /usr/local/lib/LabVIEW-8.6/models/slider_d.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/slider_f.3ds
lvtest /usr/local/lib/LabVIEW-8.6/models/slider_t.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/slidet.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/squreled.3ds
lvtest /usr/local/lib/LabVIEW-8.6/models/tab.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/tank.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/tb_h.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/tb_h_in.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/therm_e.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/therm_h.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/toggle_b.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/toggle_s.ptc
lvtest /usr/local/lib/LabVIEW-8.6/models/toggle_su.ptc
lvtest /usr/local/lib/LabVIEW-8.6/nids.so
lvtest /usr/local/lib/LabVIEW-8.6/niwebsrv.so
lvtest /usr/local/lib/LabVIEW-8.6/patchlib/
lvtest /usr/local/lib/LabVIEW-8.6/rtapp.rsc
lvtest /usr/local/lib/LabVIEW-8.6/webserver/
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/liblvauthmodule.so.1.0.0
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/liblvrfpmodule.so.1.0.0
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/liblvsnapshotmodule.so.1.0.0
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/lvauthmodule.so
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/lvrfpmodule.so
lvtest /usr/local/lib/LabVIEW-8.6/webserver/LVModules/lvsnapshotmodule.so
lvtest /usr/local/lib/LabVIEW-8.6/webserver/logs/
lvtest /usr/local/lib/LabVIEW-8.6/webserver/logs/access.log
lvtest /usr/local/lib/LabVIEW-8.6/webserver/logs/error.log
lvtest /usr/local/lib/LabVIEW-8.6/webserver/mime.types
lvtest /usr/local/lib/LabVIEW-8.6/webserver/modules/
lvtest /usr/local/lib/LabVIEW-8.6/webserver/modules/libcopyModule.so
lvtest /usr/local/lib/LabVIEW-8.6/webserver/modules/libdirModule.so
lvtest /usr/local/lib/LabVIEW-8.6/webserver/modules/libespModule.so
lvtest /usr/local/lib/LabVIEW-8.6/webserver/niwebserver.conf.defaults
lvtest /usr/local/lib/libguide.so
lvtest /usr/local/lib/libmkl.so
lvtest /usr/local/lib/libmkl_def.so
lvtest /usr/local/lib/libmkl_lapack64.so
lvtest /usr/local/lib/libmkl_p3.so
lvtest /usr/local/lib/libmkl_p4.so
lvtest /usr/local/lib/libmkl_p4p.so

Xyne · 2010-12-27 22:20:34

Arch (generally) doesn't use /usr/local, so I would install the contents of $srcdir/usr/local to $pkgdir/usr.
What executable are you expecting to find? Executables are normally installed in /usr/bin. I don't see anything in that list that is clearly an executable. You may need to create a simple script yourself to launch the application, e.g.

#!/bin/bash
cd /usr/lib/LabVIEW-8.6/ && ./foo "$@"

where "foo" is the name of the command to execute, if there is one. You would install the script to $pkgdir/usr/bin with

install -Dm755 "$srcdir/scriptname" "$pkgdir/usr/bin/scriptname"

.

Again, it depends on the expected executable.

sportscliche · 2010-12-28 00:24:03

I modified PKGBUILD as indicated

cp -ra ${srcdir}/usr/local $pkgdir/usr

and rebuilt lvtest from scratch, but I still can't get my Labview applications to run. For clarification: these separate application files are what I was referring to as "executables" since that is how they are identified in the file manager. They are not part of the .rpm files I'm trying to install. These custom-made executables are built on another box that has Labview's full developer software package. They will run on another computer without the licensed Labview software provided the two .rpm files are installed correctly. The .rpm files generate the (free) runtime engine. So when I set this up with alien -> .deb -> dpkg on Ubuntu, a simple double-click on the application/executable file starts the Labview runtime engine and all is well.

Since I don't see anything like a script coming in (ie. the ./foo in the previous post), I was thinking that maybe I don't have permissions set correctly? I'm guessing there is something that rpm and dpkg are doing automatically that I must explicitly write into my PKGBUILD.

Sorry for the confusion and I appreciate the help.

Xyne · 2010-12-28 08:26:03

What happens when you try to run the executables? Post the command that you are using to try to run them and the full output.

Have you made them "executable" with "chmod +x /path/to/executable"?
Have you placed them on your path? Use "echo $PATH" to display your path. You should probably install them to /usr/bin by either including them in the same package as the libraries or by creating a separate package that depends on the library package. Install them with "install -Dm755..." in the PKGBUILD to make them executable.
The library path may be hard-coded if the executables were built on another system. You may need to install to /usr/local/ as you did at first because of this.
You may need to make some of the library files executable with "chmod +x". Compare the files in your package to the files on the computer with the full developer package using "ls -lR /usr/local/lib/LabVIEW-8.6/" (or whatever path it uses). If you notice differences in file paths or permissions, adjust the PKGBUILD.
If you have access to an Ubuntu box then you should check the file paths and permissions for the LabVIEW files there too.

sportscliche · 2010-12-28 23:28:46

OK, I'm making progress. I took a look at the successful runtime engine install on the Ubuntu box. I found that dpkg copied the alien-converted rpm packages to /usr/local/lib/ with root privileges. The only way I can launch an application (foo) generated by Labview's developer software (on a different computer that I don't have access to) is to double-click on the foo icon. According to the icon properties, this tells Ubuntu to "execute". I have no idea how to run it from the terminal, including just typing foo. And yes, the permissions are executable.

More file searching on Ubuntu showed showed three possibly relevant additional directories (errors, etc, licenses) placed in /usr/local/natinst/share/. The directory etc contains a single file share.dir with one line of code listing the file path I've indicated in the previous sentence.

Back to Arch. My initial PKGBUILD shown in my first post copied the libraries to /usr/local/lib/ the way Ubuntu likes it, so I edited back to that. "echo $PATH" showed 8 possible paths so I picked /usr/bin/. I added foo to the source field, generated the md5sum, and added the following line to build:

install -Dm755 foo $pkgdir/usr/bin/foo

After a successful makepkg and pacman, typing foo from the command line gives:

Can't find LabVIEW runtime library liblvrt.so.8.6
Make sure this library is installed in your LD_LIBRARY_PATH
search path, or in /usr/lib

That makes sense because that file is located in /usr/local/lib/LabVIEW-8.6/. So do I change where the libraries reside or instruct foo to look in the right place?

Xyne · 2010-12-28 23:33:51

Move the libraries back to /usr/lib/. The executable is already looking for them there and it follows Arch's packaging standards.

sportscliche · 2010-12-29 00:00:42

Editing back to

cp -ra ${srcdir}/usr/local $pkgdir/usr

in PKGBUILD puts the library files where they are supposed to be. After repeating the build from scratch, I confirm the offending file is now at:

/usr/lib/LabVIEW-8.6/liblvrt.so.8.6.0

Yet the identical error message persists...it can't find this file located in the Labview sub-directory.

Xyne · 2010-12-29 15:07:27

Try this in a terminal

export LD_LIBRARY_PATH="/usr/lib/LabVIEW-8.6:$LD_LIBARARY_PATH"
foo

If that works then you can create a script that does the same thing and install that in /usr/bin.

sportscliche · 2010-12-30 20:52:16

First I ran the following from the terminal:

echo $LD_LIBRARY_PATH

which returns a blank line. Next

export LD_LIBRARY_PATH="/usr/lib/LabVIEW-8.6:$LD_LIBRARY_PATH"
echo $LD_LIBRARY_PATH
/usr/lib/LabVIEW-8.6:
foo

Can't find LabVIEW runtime library liblvrt.so.8.6
Make sure this library is installed in your LD_LIBRARY_PATH
search path, or in /usr/lib

Tried chmod +x on the directory and liblvrt.so.8.6 with no effect. Xyne, I appreciate the help that you'vre been providing on this problem!

Xyne · 2010-12-30 21:22:25

Hmmmm, I just noticed something...

sportscliche wrote:

I confirm the offending file is now at:

/usr/lib/LabVIEW-8.6/liblvrt.so.8.6.0

Can't find LabVIEW runtime library liblvrt.so.8.6
Make sure this library is installed in your LD_LIBRARY_PATH
search path, or in /usr/lib

/usr/lib/LabVIEW-8.6/liblvrt.so.8.6.0
Can't find LabVIEW runtime library liblvrt.so.8.6

Assuming those aren't typos, it seems to be looking for the wrong file. Try this at the end of the PKGBUILD:

cd "$pkgdir/usr/lib/LabVIEW-8.6/"
ln -s liblvrt.so.8.6.0 liblvrt.so.8.6

If that doesn't work, try renaming the files to remove the ".0":

cd "$pkgdir/usr/lib/LabVIEW-8.6/"
rename '8.6.0' '8.6' *

Last edited by Xyne (2010-12-30 21:23:03)

sportscliche · 2010-12-30 23:29:29

Ka-ching! Well solved Xyne. Your first suggestion did the trick. The Labview runtime engine is now functioning here on Arch. From the runtime GUI I can open foo and it runs perfectly. The export LD_LIBRARY_PATH stuff is also necessary before running foo.

There is something a little puzzling that I'd like to understand. PKGBUILD has the following line of code:

install -Dm755 foo $pkgdir/usr/bin/foo

where foo is the Labview application built previously on another machine. I was expecting that typing foo at the terminal would open the runtime engine AND foo. But it only opens the former and stops there, waiting for me to specify an application/executable. It appears to be ignoring foo even though it was explicitly installed by PKGBUILD. So I'm essentially using foo to only open the RTE -- from there I must open foo from the menu. Why is that?

Many thanks. There's no way I could have worked this out on my own.

Last edited by sportscliche (2010-12-31 01:33:02)

Xyne · 2010-12-31 10:42:32

I don't understand. After running foo, foo requests that you specify the path to foo, i.e. itself? If it needs to invoke itself (which I find strange, but I don't know anything about foo's internals or what it does), then maybe it's still looking in /usr/local/bin. You could try installing a symlink with the PKGBUILD (ln -s /usr/bin/foo "$pkgdir/usr/bin/local"), or move everything back to /usr/local. If might also be possible to specify the path to foo with a command-line option, in which case I would create a wrapper script that exports the necessary variables and then invokes the binary with the necessary options.

Is is possible to change the installation paths of the developer package to use /usr/ instead of /usr/local? It seems that this would alleviate most of the effort in packaging the compiled executables. If not then I would consider filing an upstream feature request to have executables properly use system variables for locating libraries and executables, especially if the developer's package is expensive.

If you plan to package more executables then you should probably create a separate package for the libraries and then make the executable packages depend on this. If you use these packages across different machines then you will probably want to create your own custom local repo too.

I'm glad that you've got it working now. Please edit the first post and mark the thread as [SOLVED].

sportscliche · 2011-01-03 00:26:16

Xyne wrote:

I don't understand. After running foo, foo requests that you specify the path to foo, i.e. itself?

That's essentially what's happening. Since I can't find any script in the package of .rpm files, the only way I know how to get the runtime engine (RTE) going is by launching the pre-built application foo. This starts the RTE, but it is not aware of foo so it halts and asks me to open any file of my choice via the GUI. So I click through the directories until I get to foo. It's not the clean solution I was hoping for (i.e. what happens with the RTE on Ubuntu as described in earlier posts) but it is a solution.

move everything back to /usr/local.

Tried a PKGBUILD with /usr/local/ and got exactly the same result.

If might also be possible to specify the path to foo with a command-line option, in which case I would create a wrapper script that exports the necessary variables and then invokes the binary with the necessary options.

I understand the concept you are suggesting, but I'm not knowledgable enough to do it.

If not then I would consider filing an upstream feature request to have executables properly use system variables for locating libraries and executables, especially if the developer's package is expensive.

This is a great suggestion, but when I was last on National Instruments website it was explicitly stated that they were not supporting Linux package managers other than rpm. Not even dpkg. I doubt they would want to invest any effort to support what is likely to be only one Arch user (me).

Xyne · 2011-01-03 10:37:30

sportscliche wrote:

Xyne wrote:
If might also be possible to specify the path to foo with a command-line option, in which case I would create a wrapper script that exports the necessary variables and then invokes the binary with the necessary options.
I understand the concept you are suggesting, but I'm not knowledgable enough to do it.

Does foo accept any command-line arguments? I would try the following to see if it at least provides a help message: "foo --help", "foo -h", "foo -?" If it doesn't support any options then maybe it's possible to create an executable that does using the developer package, but as I have no idea how the executables are created, I really don't know how overly optimistic that is.

If it does accept an option to specify the binary path then you could create a script like this:

#!/bin/bash
/path/to/foo --option /path/to/foo

Otherwise, if you find that you can place foo somewhere where it can find itself, then you can use a similar script just to launch foo, and install that script to $pkgdir/usr/bin.

Check where the files are installed on Ubuntu. It must depend on the absolute or relative filepaths. Also check the $PATH and $LD_LIBRARY_PATH on Ubuntu. There must be something that you're forgetting to recreate on Arch, because nothing here is distro-specific. The RPM package is just dumping files to a set location. The environment may be different, but it can be recreated easily.

sportscliche wrote:

This is a great suggestion, but when I was last on National Instruments website it was explicitly stated that they were not supporting Linux package managers other than rpm. Not even dpkg. I doubt they would want to invest any effort to support what is likely to be only one Arch user (me).

It's not really an issue of supporting a specific package manager. It's about not being so unbelievably daft as to hardcode paths into binaries that are intended to be distributed. You didn't pay to produce executables that can only be run on a few select distros, and the only thing that makes this difficult is that they were too lazy to make this configurable, despite how easy it would be to do so. The fact that foo requests its own path shows that they have the code to handle run-time detection of paths, so there is no excuse for this. If they really refuse to support this then I would have a nice collection of four-letter words for them, along with a demand for a full refund as I am unable to use their product as intended... although it would probably be better to ask for the refund first and insult them later.

Last edited by Xyne (2011-01-03 10:38:08)

sportscliche · 2011-01-03 23:37:03

I'm happy to report this problem is now completely and cleanly solved. The difficulty I encountered after the library linking was a combination of my newbie stupidity and the different behavior of the PCManFM file manager that installs with LXDE. Specifically, the executables open with a double left-click or right-click execute on the three Debian/LXDE boxes I was using as reference during this process (Lubuntu 10.04, 11.04, Mint LXDE). Not so with Arch/LXDE that I just built. I had checked this during my initial troubleshooting, but neglected to do it after the library link suggested by Xyne. Lesson learned: Trust the command line, not the GUI. And this may not even be an issue if you are running another desktop environment and/or file manager where the mouse clicks work.

For the sake of completeness, here is the detailed procedure for installing the LabVIEW runtime engine (RTE) on Arch, relying entirely on pacman. This assumes you have an application `foo' that was built by the premium version of Labview with the developer package. You must know the exact version of Labview/Linux that produced foo. Download the corresponding two .rpm files that will generate the RTE after registering on the NI website. Extract the various libraries from the .rpm files first (independent of PKGBUILD) to see how things are named. You'll need that information to edit the following PKGBUILD for your specific version of the RTE. Then put just the two .rpm files in the same directory as the PKGBUILD file.

pkgname=lvrte
pkgver=1
pkgrel=1
pkgdesc="Installs the LabVIEW runtime engine"
arch=("i686")
license=("GPL")
makedepends=("rpmextract")
# Download the appropriate .rpm files from the NI website.
source=("labview86-rte-8.6.0-1.i386.rpm" 
"labview-rte-aal-1.1-1.i386.rpm")

# The mdsums are generated by running makepkg -g
md5sums=("37b43da794fd9c61d0c5e3c9cfa56628"
         "a2110e5b5677351095bd93e5b1aa5bea")

# You will need to edit lines 3,4,6,7 in the following build for your specific RTE.
build() {
    cd ${srcdir}
    rpmextract.sh labview-rte-aal-1.1-1.i386.rpm
    rpmextract.sh labview86-rte-8.6.0-1.i386.rpm
    cp -ra ${srcdir}/usr/local $pkgdir/usr
    cd "$pkgdir/usr/lib/LabVIEW-8.6/"
    ln -s liblvrt.so.8.6.0 liblvrt.so.8.6
}

Now run "makepkg -s" followed by pacman -U on the pkg.tar.xz (as root) on the file that was just generated. This installs a working Labview RTE on Arch.

The next step is to open your Labview application foo. Since mine won't open from the file manager GUI, I use the following script, edited for my specific library. Pick any convenient location for the script file; I used my home directory:

#!/bin/bash
export LD_LIBRARY_PATH="/usr/lib/LabVIEW-8.6:$LD_LIBRARY_PATH"
/path to foo/foo

Make sure foo and the script have the proper permissions to execute; I used chmod 755. You could alternatively run the above two instructions directly from the command line, but it's simpler to use a script that can be opened from your application menu. You are then one mouse-click away from launching directly into your Labview application.

Many thanks to Xyne for the insight needed to solve this problem!

Last edited by sportscliche (2011-01-04 09:19:59)

Arch Linux

#1 2010-12-27 11:57:10

Labview runtime engine [SOLVED]

#2 2010-12-27 13:13:41

Re: Labview runtime engine [SOLVED]

#3 2010-12-27 14:12:23

Re: Labview runtime engine [SOLVED]

#4 2010-12-27 22:20:34

Re: Labview runtime engine [SOLVED]

#5 2010-12-28 00:24:03

Re: Labview runtime engine [SOLVED]

#6 2010-12-28 08:26:03

Re: Labview runtime engine [SOLVED]

#7 2010-12-28 23:28:46

Re: Labview runtime engine [SOLVED]

#8 2010-12-28 23:33:51

Re: Labview runtime engine [SOLVED]

#9 2010-12-29 00:00:42

Re: Labview runtime engine [SOLVED]

#10 2010-12-29 15:07:27

Re: Labview runtime engine [SOLVED]

#11 2010-12-30 20:52:16

Re: Labview runtime engine [SOLVED]

#12 2010-12-30 21:22:25

Re: Labview runtime engine [SOLVED]

#13 2010-12-30 23:29:29

Re: Labview runtime engine [SOLVED]

#14 2010-12-31 10:42:32

Re: Labview runtime engine [SOLVED]

#15 2011-01-03 00:26:16

Re: Labview runtime engine [SOLVED]

#16 2011-01-03 10:37:30

Re: Labview runtime engine [SOLVED]

#17 2011-01-03 23:37:03

Re: Labview runtime engine [SOLVED]

Board footer