Problem with CIN loading

[Mathilde38]

Hi all,

We have a problem with an application using CIN on Linux CentOS 64 bits (LabVIEW 8.6)

When we launch this application, we get a first error message :

"LabVIEW : Resource not found.

An error occured loading VI 'SCAL_CIN_Sys_Reech.vi.

LabVIEW load error code 3 : Could not load front panel"

then a second error message :

"Missing suvVI SCAL_CIN_Sys_Reech.vi in VI Reech.vi.

VI has an error of type 2228. The full develpment vesrion of LabVIEW is required to fix the errors."

This application is launched without error in a first partition CentOS 64 bits.

But in a CentOS 64 bits modified (we don't know exactly all modifications made by our customer), we get this error.

So I have two questions :

- Have you any ideas of what can cause this error ?

- Can we know all dependencies of a CIN ? (equivalent of "ldd" command for a library)

I precise that other LabVIEW applications (without CIN) works fine in the same OS, and that there is only LV8.6 runtime installed (not all development environment).

Thanks you in advance

Mathilde

[rolfk]

The error message is quite clear. LabVIEW wants to have the front panel resource but that is not present. Usually LabVIEW removes all front panel resources in built applications except for VIs whose front panel is displayed or included in the application as "always included" which would indicate that the VI is likely loaded dynamically, which requires the front panel to be available.

Why it seems to require this only for the CIN VI which is likely just included as a subVI and hence doesn't really need the frontpanel is however a strange thing. There is not something like ldd for LabVIEW, since the front panel resource is included in the embedded VI itself.

The only thing I can think of, is that the CIN resource itself (an ELF shared library in fact that someone must have developed at some point) tries to link to a different shared library that is not present or can not be located on that system, and the LabVIEW loader somehow gets confused and issues the wrong error message. When LabVIEW tries to instantiate the CIN code resource it loads it as shared library into memory and that loading will be aborted by the kernel if not all dependencies can be resolved. However the CIN shared library is wrapped with a CIN code resource and embedded in the VI, which is embedded in the executable and there is no easy way to extract that original shared library to apply the ldd command. A sometimes workable approach is to look in the temporary directory for files that look like lv*, which is usually an extracted CIN shared library that LabVIEW then loads from there, but for bigger applications that can be unworkable as LabVIEW can generate many such temporary files and it's then hard to find the right one.  

[Mathilde38]

Thank you for this answer.

Some additional details : we have the .lsb that is loaded into the CIN, and we have the C code. So we know "direct" dependencies. But I wonder if there are other LabVIEW dependencies (for example library as "libcin.a" that is in the cintools directory, or others...).

So I tried to run a "ldd Reech.lsb" command, but it doesn't work.

I also tried to build a little application that calls my CIN vi (app1), and another that doen't call CIN (app2).

When I launch the first one, a shared library is effectively created in the /tmp directory : LVOPnxQ6

I runned : ldd LVOPnxQ6

--> linux-gate.so.1

--> libc.so.6

--> lib/ld-linux.so.2

I also runned : ldd app1

--> linux-gate.so.1

--> libdl.so.2

--> libpthread.so.0

--> libc.so.6

--> lib/ld-linux.so.2

and : ldd app1

--> linux-gate.so.1

--> libdl.so.2

--> libpthread.so.0

--> libc.so.6

--> lib/ld-linux.so.2

So it appears that there are no additional dependencies due to the CIN...

Secondly, I tried to remove write rights of the /tmp directory. I have an error : "error 8 creating temporary LVSB resource file". So the error of my customer is not due to an access right problem.

If you have any idea...

Thanks

Mathilde

[Mathilde38]

After comparing packages installed in a CentOS where our application works and a CentOS where our application doen't work (CIN loading problem), we found that the missing package was : compat-libstdc++-296-2.96-138

Apparently, the absence of this package prevent the CIN from loading...

Mathilde

[rolfk]

Looks like a C runtime dependency, and most likely caused by your CIN being compiled with gcc 2.96. Not sure why ldd wouldn't show that dependency but I'm by no means a linux expert.