Labview doesn't work with linux kernel 2.6

[Pascal-P]

Labview 7.0 worked nicely with Mandrake Linux 9.1 (kernel 2.43). It does't work at all since my computer has been upgraded to Mandrake Linux 10.0 (new kernel 2.6). Do you know how to solve that problem?

[David Duffey]

Could you send me the current kernel version that you are running (uname -a), and version of glibc? (ls -al /lib/libc*).

I'm using a Debian system with glibc 2.3.2 and kernel 2.6.7 (and 2.6.3) without problem. We think we know what is causing LabVIEW not to execute, but we don't know why it changed and exactly what has caused the change (if it is glibc or the kernel).

If you feel comfortable compiling your own kernel, I suggest downloading the stock linus source and trying that out. That's what I'm using.

Thanks,

[David Duffey]

Also,

When you "upgraded" did you do a fresh install, or did you install to the existing, formated, filesystem(s)?

-Duffey

[Pascal-P]

I thank you for the answer, David.

The Kernel I use is a 2.6.3-7mdk (Mandrake)

On the following lines you'll find the answer to the ls -al /lib/libc*

-rwxr-xr-x 1 root root 1281788 feb 16 15:02 /lib/libc-2.3.3.so*
lrwxrwxrwx 1 root root 17 jun 22 11:52 /lib/libcom_err.so.2 -> libcom_err. so.2.1*
-rwxr-xr-x 1 root root 5860 feb 26 09:54 /lib/libcom_err.so.2.1*
-rwxr-xr-x 1 root root 18368 feb 16 15:02 /lib/libcrypt-2.3.3.so*
lrwxrwxrwx 1 root root 17 jun 22 11:51 /lib/libcrypt.so.1 -> libcrypt-2.3. 3.so*
lrwxrwxrwx 1 root root 13 jun 22 11:51 /lib/libc.so.6 -> libc-2.3.3.so*


I'm a new linux user. I don't feel comfortable compiling my kernel. Do you think I have to re-instal
l my system from scratch in order to use Labview?


Thank you in advance
Pascal

[David Duffey]

Okay, found a solution.

Mandrake (and Fedora Core 2, FC2) are using a new directory indexing feature on filesystems. This causes "." and ".." not always to be listed first, and LabVIEW currently relies on this behaviour (you can see this by doing ls -af in a directory).

Fortunately, you can turn it off for the time being (there is no loss in features). On all of your ext3 partitions, you'll want to run (as root):

tune2fs -O ^dir_index /dev/yourpartition

You can find out the partition(s) by running "mount", here is what mine looks like:

dduffey$ mount
/dev/hdb2 on / type ext3 (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
sysfs on /sys type sysfs (rw)
usbfs
on /proc/bus/usb type usbfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

in which case I did:

tune2fs -O ^dir_index /dev/hdb2

(my only ext3 partition)

You should immediatly be able to use LabVIEW. This changes a flag on the filesystem, and should work across reboots (unless Mandrake/RedHat resets the dir_index in their startup scripts, highly unlikely).

Duffey

[Pascal-P]

Thank yo, it works now...

[Craig_S.]

There is a problem with LabVIEW running on Linux kernel 2.6 where LabVIEW will crash or hang on launch.

The problem is that kernel 2.6 turns on by default a filesystem optimization which causes the current and parent directory entries (. and ..) to no longer appear first in the output of the system call which reads directory contents (readir()). This confuses LabVIEW and causes the problem. Turning off the feature in the filesystem restores LabVIEW's sanity.

Do the following as root to fix the problem:

# tune2fs -O "^dir_index" /dev/hda1

where /dev/hda1 is the filesystem where LabVIEW is installed. Actually, you should do this for every local filesystem you might access using LabVIEW. Use "df -l" to list these filesystems.