Shared Linux libraries in LabView 7.1

[Raistlin]

We are trying to transfer a rather large application from Windows to Linux. The major problem I seem to encounter is the use of shared libraries. We wrote a large part of our software in C, but when I try to make a shared library I do not succeed to export the functions. A first simple test file (with a meaningless little function) already gave the problem of not exporting the function in the shared library to LabVIEW. Not only are the functions not listed when configuring the Call Library Function node, typing the function name and providing the right arguments still gives the message that the function was not found.

The source code was the following :

long first(long a);

long first(long a) {

  long b;

  b = a;

  return b;
}

The command :

 gcc -fPIC -shared -o libtest.so firstso.c

Are any extra compilation flags or keywords required ? I already tried a whole bunch (including visibility attributes), but the problem remains the same.

[JorisV]

Hi,

I'm not really a Linux expert myself but can you give the following example a try? This tutorial describes how to create a shared lib. for LabVIEW:

http://zone.ni.com/reference/en-XX/manuals/370109B-01/06Chap2_03/

Can you let me know if this example works?

If not, than can you post the so, you've created and give us some more details about the Linux version,...

Regards.

JorisV

[Raistlin]

I will try to use the fno-gnu-linker flag, maybe this solves some things. I am using GCC 4.0 (i think) on SUSE 10.0.

I also wonder if anything has to be added to the bashrc file to make the library available, also this seems unlikely. I will try playing with these things tomorrow to see what the resut is.

[rolfk]

---

@Raistlin wrote:
We are trying to transfer a rather large application from Windows to Linux. The major problem I seem to encounter is the use of shared libraries. We wrote a large part of our software in C, but when I try to make a shared library I do not succeed to export the functions. A first simple test file (with a meaningless little function) already gave the problem of not exporting the function in the shared library to LabVIEW. Not only are the functions not listed when configuring the Call Library Function node, typing the function name and providing the right arguments still gives the message that the function was not found.

The source code was the following :

long first(long a);

long first(long a) {

  long b;

  b = a;

  return b;
}

The command :

 gcc -fPIC -shared -o libtest.so firstso.c

Are any extra compilation flags or keywords required ? I already tried a whole bunch (including visibility attributes), but the problem remains the same.

---

I can't give you the solution here, but there are several issues with shared library function export.

First only on Windows does the Call Library Node have support to enumerate the exported functions and populate the Ring Control. On all other platforms this Ring Control is always disabled.

There are ussues about name decorations and such when compiling a C source file with a CPP compiler. Also I've had quite some troubles in the past to get a shared library to export its functions and fiddling with the make file eventually made the functions available for LabVIEW to call.

My command lines usually look somewhat like this if I remember correctly, although I usually use makefiles for this:

gcc -fPIC -I. -O3 libtest.o libtest.c
gcc  -shared -Wl, -o libtest.so libtest.o

Rolf Kalbermatter

[Raistlin]

I will give the 'fiddling' a try. I thought name decorations would not be an issue since no classes or anything are used. I suppose compiling a library and calling it from another C code might help me. I'll take a look at it.

I left the Makefile out for now, but off course it will be necessary for the whole project. And about the stander gnu linker, if I take a look at it it seems this only seems to be relevant for Solaris. Can anyone confirm this, so I don't need to give this any attention ?

[Raistlin]

After a long time I would like to give an update on this issue. I picked up this conversion again lately, and noticed I was working on x64 distribution without being aware of it. This explains why LabVIEW could not access the library. Everything works fine now with 4.0, and I'm sure the conversion to 4.1 will also be smooth.

[rolfk]

---

@Raistlin wrote:
After a long time I would like to give an update on this issue. I picked up this conversion again lately, and noticed I was working on x64 distribution without being aware of it. This explains why LabVIEW could not access the library. Everything works fine now with 4.0, and I'm sure the conversion to 4.1 will also be smooth.

---

Thanks Raistlin for posting this. It would not have occurred to me to suggest checking this, eventhough I know from other Opn Source projects that this is a very common problem trying to create 32bit components on a 64bit Linux distribution, without having the entire 32bit toolchain setup correctly too.
You should be able to install the 32bit GCC toolchain on a 64bit system and then everything should work but I seem to remember that getting everything configured right can be a bit of a hassle. The easiest thing if you are not into GCC tweaking yourself probably still is to just install the 32bit distrubution at this time 😉

Rolf Kalbermatter

[Raistlin]

Well, I managed to compile the 32 bit version on a 64 bit system (using the -m32 flag), so that was not a major problem. The only problem I ran into was linking with 32 bit libraries. Where you normally use :

-L /PATH_TO_LIBSOMETHING -llibsomething

I needed to use :

/PATH_TO_LIBSOMETHING/libsomething.a

Maybe it's just some peculiarity of gcc 4.1, all in all I'm glad everything finally linked.

Message Edited by Raistlin on 08-18-2006 03:25 AM