Can Call Library Node support nested .so libraries?

[J_Bangasser]

We have created a .so library that makes calls to other .so libraries that are dynamically linked, but the Call Library Node does not recognize the dynamically linked .so.  We do not want to statically link these libraries.  Is there another way around this?

Thanks.

Julia

[Randy_H]

Julia,

I have a couple of questions. First, I assume that the first .so is a LabVIEW built one. Is this correct? Second, is the other .so in one of the system standard library paths? If it is, then you should just use the name of the library in the Call Library Node and not the full path. If you use the full path, LabVIEW will make a copy of that library and store it in the data subfolder next to your LabVIEW built .so file. Is this what you are seeing? If not, then we will need some more information to better assist you.

Randy Hoskin

[J_Bangasser]

The first .so is a C library compiled on Linux Red Hat.  We use LabVIEW's Call Library Node to interface to this C-library.  Teh second .so is just another c_library compiled on Red Hat.   The problem occurs since the first .so is built, it dynamically links to the second .so, it does not staticall link.

Does that help?

[Randy_H]

Julia,

OK, I think I understand a bit better. If you run 'ldd' on the first .so, does it correctly find the second .so? If so, then I'm not totally sure what might be wrong. When LabVIEW loads the first .so, it would do it in a normal dlopen way. That should then cause the first library to load the second library. LabVIEW uses this method for the analysis libraries, so I know that it works. I think the 'ldd' information will help us resolve this issue.

I guess the other possibility is that the first library does a dlopen itself on the second library. If that is true, then you would need to have LabVIEW call some sort of Init function in the Call Library Node before calling the fuction you want to use.

Randy Hoskin

[Randy_H]

Julia,

Any news on the 'ldd' results?

Randy Hoskin