File with .so extension built with C++ initially for older version causing problems.

[Mordred]

I am running a subVI file using Labview 7.1 under Linux Mandriva operating system. I tried calling a library function with a .so extension but the error 'Function not found in library' was up.

The .so function that was called, was initially built using C++ for Labview 6.0. Could the change of Labview versions be the cause of the problem or what is? What do I need to do? Urgently need help, thanks.

[rolfk]

---

@Mordred wrote:

I am running a subVI file using Labview 7.1 under Linux Mandriva operating system. I tried calling a library function with a .so extension but the error 'Function not found in library' was up.

The .so function that was called, was initially built using C++ for Labview 6.0. Could the change of Labview versions be the cause of the problem or what is? What do I need to do? Urgently need help, thanks.

---

What do you mean with the .so was create with C++ for LabVIEW 6.0? Do you mean you created the shared library with gcc and you could interface to it from LabVIEW 6 with the Call Library Node while you can't interface the same shared lib from LabVIEW 7.1 anymore?

In general using C++ will cause name decorations to the exported function symbols and that means the names as they get exported really look different than what they look in the header file (and therefore what you would usually try to load in the Call Library Node).
 
You can avoid name decorations by embedding the function prototypes between

#ifdef __cplusplus
extern "C" {
#endif

int function1(parameters);
int function2(parameters);

#ifdef __cplusplus
}
#endif

Another issue might be that the shared library was created on an old system and links to some libc and other libraries that provided symbols that changed or got discontinued in the version installed by your Mandriva distribution. Initialization of the shared library at link time might then fail and LabVIEW only sees that it could not link to a specific symbol. It does not know if the symbol is really not there or if the dlsym() function failed because the link operation failed.

Rolf Kalbermatter

[Mordred]

          Hi, sorry for the not very timely correspondence, but here goes.         

@rolfk wrote:

---

What do you mean with the .so was create with C++ for LabVIEW 6.0? Do you mean you created the shared library with gcc and you could interface to it from LabVIEW 6 with the Call Library Node while you can't interface the same shared lib from LabVIEW 7.1 anymore?

---

Exactly. I was baffled when such a thing happened. Previously on LabVIEW 6.0 and on another Linux version(I am not sure which), everything was running completely fine. Anyway I was not the one who created the shared library and interfaced it with LabVIEW 6.

Now on LabVIEW 7.1, this problem came up.

It couldn't be due to the C++ name decorations, could it? Because if it can previously run on LabVIEW 6.0 involving the same C++ files, how come not on  LabVIEW 7.1? Please suggest some reasons for this.

---

Another issue might be that the shared library was created on an old system and links to some libc and other libraries that provided symbols that changed or got discontinued in the version installed by your Mandriva distribution. Initialization of the shared library at link time might then fail and LabVIEW only sees that it could not link to a specific symbol. It does not know if the symbol is really not there or if the dlsym() function failed because the link operation failed.

---

   
         What can I do if this is the cause of the problem? Should I still go about doing the C++ files or something else? Please advise me.

          Mordred

[rolfk]

---

@Mordred wrote:
        

---

Another issue might be that the shared library was created on an old system and links to some libc and other libraries that provided symbols that changed or got discontinued in the version installed by your Mandriva distribution. Initialization of the shared library at link time might then fail and LabVIEW only sees that it could not link to a specific symbol. It does not know if the symbol is really not there or if the dlsym() function failed because the link operation failed.

---

   
         What can I do if this is the cause of the problem? Should I still go about doing the C++ files or something else? Please advise me.

---

If this is the problem recompiling the shared library with the gcc development toolchain installed on your new Linux system should help.

Rolf Kalbermatter

[Mordred]

I am using Linux Mandriva 2005. It has something called KDevelop.

Could you give me a rundown on how recompiling a shared library can be done? Do I need to use Makefile, and/or a specifically compatible gcc compiler in which LabVIEW supports?

[rolfk]

---

@Mordred wrote:
I am using Linux Mandriva 2005. It has something called KDevelop.

Could you give me a rundown on how recompiling a shared library can be done? Do I need to use Makefile, and/or a specifically compatible gcc compiler in which LabVIEW supports?

---

I haven't done anything with KDevelop. What I usually do for the simple shared libraries I use is to modify an existing makefile to create the library for me. If you have the source code of the shared library it comes likely with a more or less ready Makefile. Otherwise you might need to run gcc directly from the command line but it depends a bit on the gcc versions you have. I have really no idea about Mandriva in any version so you will have to dig in there a bit.

something like:

gcc -I<your include paths> -D<your defines> <your source file> -o <object file>

gcc -shared -Wl,--export-dynamic -o <output file> <object files>

should do the trick.

Rolf Kalbermatter

Message Edited by rolfk on 03-29-2006 08:16 PM

[Mordred]

Thanks. I also realised that it is possible to build shared libraries(.dll for Windows, not sure for Linux) from LabVIEW's tools itself. In addition, I found the g++ program which consists simply of two boxes and a command line. Is this the program that is used to create a shared library with .so extension for Linux?

For some reasons, I was unable to locate the Makefile for the .cpp files. Is this because the shared libraries were created using LabVIEW and not gcc or g++? Is this possible?

Also, when a shared library for Linux is created(whether using LabVIEW or gcc), does it automatically generate a Makefile file?

[rolfk]

---

@Mordred wrote:
Thanks. I also realised that it is possible to build shared libraries(.dll for Windows, not sure for Linux) from LabVIEW's tools itself. In addition, I found the g++ program which consists simply of two boxes and a command line. Is this the program that is used to create a shared library with .so extension for Linux?

For some reasons, I was unable to locate the Makefile for the .cpp files. Is this because the shared libraries were created using LabVIEW and not gcc or g++? Is this possible?

Also, when a shared library for Linux is created(whether using LabVIEW or gcc), does it automatically generate a Makefile file?

---

A shared library created in LabVIEW is quite a bit different than one created from C source files. I have only experience with LabVIEW shared libraries under Windows and am not even sure if the LabVIEW for Linux version can create them too.

Basically LabVIEW creates some temporary C files to create the interface between the exported function pointers and the actual VIs that make up the LabVIEW functions, compiles them behind the scene and throws them away afterwards leaving you with a shared library that is in fact an initialization and loader stup with some function wrappers to call the actual VI embedded in the library. If this is supported under Linux too, it is likely that LabVIEW requires you to have a properly installed gcc toolchain for this to work.

If you have cpp files, they were NOT created by LabVIEW. There must have been a developer that wrote them at some point and he likely wrote a simple Makefile too.

I'm not sure what g++ is exactly but it might be a user front end calling gcc in the background (or maybe it's now the opposite with newer GNU C compilers, I'm really not sure here). If you are not familiar with the unix shell command line then it is likely that the direct road of calling gcc might be quite a problem for you. How to setup some gui frontend such as KDevelop is beyond my knowledge as I haven't bothered with them yet.

And a Makefile might be created automatically by certain GUI frontends translating the user selections into this Makefile. But I think it would be sort of a detour for a GUI frontend developer to create a Makefile from the user selections and then invoking that Makefile. It would seem more logical to me to just call the different tools such as gcc and ld directly from the GUI frontend according to the user configuration.

In general the Makefile is not created automatically unless you use the more complicated GNU Autoconf system too, but there you have both to create the configure script as well as the Makefile template too. Using Autoconf however is something only useful for larger projects as its specifics are sometimes rather obscure to understand.

I'm afraid I can't really help you much more here. I'm still working with rather old systems under Linux and only very sporadically, and gcc in version 3.3 or something like this. For those smaller things I usually just call gcc directly from the command line and that's about it. If I compile more complex things they are usually already preconfigured Open Source projects where the Autoconf system has been used and I can simply work with  ./configure, make depend, and make.

Rolf Kalbermatter

[Mordred]

Hi. So far, I've tested the same files with another computer altogether. In that new computer, Linux Mandriva 2006 is the operating system.

To my surprise, everything was working.

Previously, the computer in which the files can't load was running on Linux Mandriva 2005 instead.

As I want to run it on the previous original computer, I had Linux Mandriva 2006 upgraded on top of the Linux Mandriva 2005 OS. However, it still does not work.

For that old computer, I have set several usernames and passwords which could access only certain folders of the files whilst for the new computer(which worked), I did not set any passwords for that similar settings, meaning access is free to all areas.

Could this password access setting also attribute to the problem?

Or is it because because although the computers were both using the same operating system, the compilers might be different? Would reformatting the computer help?

The situation here is that I want to have the files running on the original pc. Let me know what I can do to fix this problem. Thanks.

[Mordred]

Hi people, just a couple of questions regarding LabVIEW Run Time Engine this time.

Current situation: VI files were built using LabVIEW 6.0 on Linux. Shared libraries (.so files) were created and compiled with gcc and previously linked to VIs built under LabVIEW 6.0.

Questions:
1.  Is it possible to have only LabVIEW Run Time Engine 7.1 installed in order to edit the VIs(not execute them) and be able to update the VIs and save them as under LabVIEW 7.1? After that, are they able to be executed under 7.1 and how do I go about updating the VIs (as in are there any special instructions)?

2.  If I want everything to be under 7.1 now, does it mean I need to recompile all shared libraries (.so) involved?

3.  Is it possible to just link the shared libraries without recompiling them with only LabVIEW Run Time Engine 7.1 installed and without Run Time Engine 6.0?

4.  Since shared libraries were compiled using gcc and g++, does using the correct Run Time Engine version has any effect on whether they can be linked or not (using 'Call Library Function')? Are there any connections?

Would appreciate it if anyone can enlighten me on these issues. Thanks a bunch.