LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW wrappers around .so files in Linux

Hi,

I am using LabVIEW 7 for Linux. I am interested in seeing how LabVIEW wraps around C and C++ libraries.

I wrote up the following code in C:

#include "stdio.h"

//our functions
void hi();
int number();
int multiply(int i, int j);

//the function implementations
void hi()
{
printf("Hi!\n");
}

int number()
{
printf("%d %d\n",1,2);
int num = 100;
return num;
}

int multiply(int i, int j)
{
int k = i*j;
return k;
}



I then wrote up the following MakeFile to create the libraries:

COMPILER = gcc
CCFLAGS = -shared -W1,-soname,libfunctions.so.1
OBFLAGS = -fPIC -g -c -Wall

all: functions.so

functions.so: functions.o
${COMPILER} ${CCFLAGS} -o libfunctions.so functions.o -lc

functions.o: functions.c
${COMPILER} ${OBFLAGS} -o functions.o functions.c

clean:
rm -rf *.*o



I then created a LabVIEW vi that will call on the two functions using the Call Library Function node. My question to all of you is this: In LabVIEW for Windows, after calling a DLL function, it will display all of the possible functions that exist in the DLL. In LabVIEW for Linux, I was not able to preview all of the possible functions that exist in the .so file. Is there something wrong with the way that I made the .so file? Do I need to include any other syntax within the Makefile?

Also, I am having trouble in creating a shared library for the exact same code in C++. Can LabVIEW for Linux wrap around a C++ .so shared library? What would be the correct syntax in the Makefile?

Attached is a zip file that contains the C file, the object file, the shared library file, the makefile, and the vi.

I apologize for using the #include "stdio.h". I cannot seem to put in the right and left brackets in this text area.

Thanks,

Elliot
0 Kudos
Message 1 of 8
(4,612 Views)
Whoops, the attached file is now attached.
0 Kudos
Message 2 of 8
(4,599 Views)
The feature to select the function name from a drop down box was added around LabVIEW 6 but only in the Windows version. Enumerating the exported functions in a PE executable file is a little easier than in an ELF file for various reasons. So they didn't bother to get the same for non Windows platforms.

LabVIEWs Call Library Node can only really interface standard C style functions. There is no way to access the methods of a C++ object at all. In addition most C++ compilers will decorate the exported function names by default which is a pitta, also because each compiler will do the decoration in a different way. Also it seems to me a little bit of a tricky business to find out which runtime libraries you need to link with for C++ object code. In addition the C++ runtime libraries add a whole bunch of extra complications to the initialization of the shared library, which can more easily clash with some setup LabVIEW does for its environment.

I can't tell you how to create a Makefile to get your C++ sources properly compiled, since I have managed to not do any real work in C++ until now. I do know that in Visual C it is more or less enough to change the file ending form .c to .cpp to let the Visual C IDE select the C++ compiler instead. In a Makefile I would assume that you would have to create a rule for .cpp files too, and make sure that the correct compiler is invoked for that.

Rolf Kalbermatter
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 3 of 8
(4,595 Views)

@elliot.ee wrote:
Can LabVIEW for Linux wrap around a C++ .so shared library? What would be the correct syntax in the Makefile?


In general, calling a C++ library from LabVIEW isn't a problem. Please check out the External Code Reference Manual for details on the caveats. The most important parts are as follows:


  1. Exported functions should be declared 'extern "C"'. This will prevent name decoration. Check your compiler's help for more information.
  2. Only global functions and static class member functions may be called. Regular class member functions require thiscall calling conventions as opposed to C or standard.
  3. Make sure that you catch all exceptions with a catch(...) before returning control from your function to LabVIEW. (I have had problems on Linux with getting gcc to properly implement the exception handling in this situation. There's a thread around here somewhere that deals with that issue, semi-satisfactorily.)


As far as the correct syntax for the Makefile, I'm not sure. I try to avoid directly using Makefiles whenever possible because they frighten me. Fortunately, for me, KDevelop usually enables this behavior.
Message 4 of 8
(4,588 Views)
Hi,

I too am trying to create a linux library for labview (using the functions in the pvcam library for ccd cameras). There were a few things I couldn't quite understand.

1. what happens when we use printf in the library i.e. where is the text printed in labview
2. when i run a function from the library labview closes. Is there any  way to figure out where in the library this happened.


Any help would be appreciated as i am totally lost here. Smiley Sad

Thanks,
Yatin

Smiley Happy
0 Kudos
Message 5 of 8
(4,010 Views)


@yatintyagi wrote:
Hi,

I too am trying to create a linux library for labview (using the functions in the pvcam library for ccd cameras). There were a few things I couldn't quite understand.

1. what happens when we use printf in the library i.e. where is the text printed in labview
2. when i run a function from the library labview closes. Is there any  way to figure out where in the library this happened.


Any help would be appreciated as i am totally lost here. Smiley Sad

Thanks,
Yatin

Smiley Happy


1) To the console. However LabVIEW is a GUI program so unless you attach to the console of a process in some ways from outside you won't see those messages (or probably more accurate but I'm not sure you would see it in the console from which your X Windows manager was started which in most distrbutions is nowadays done automatically).

Alternatively you can use the the DbgPrintf() function privided by LabVIEW instead. It will open a GUI window where the messages are printed in.

2) This means you are doing something bad in your library such as referencing an invalid or NULL pointer. Use a debugger and attach to your LabVIEW process.

Rolf Kalbermatter


Message Edited by rolfk on 07-01-2008 02:32 PM
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 6 of 8
(3,993 Views)
Hi Rolf,

thanks for the info. There's just one thing, how can I attach a debugger to the c codein labview.. some pointers would really be helpful because  i am quite new to this...

Smiley Happy
Thanks,
Yatin
0 Kudos
Message 7 of 8
(3,976 Views)
Hi Yatin,

You can attach certain debuggers to running processes. The most popular debugger for the Linux environment is GDB and is often included with major distributions. You can use the "attach" command along with the running process ID to break into a running process and use the debuggers functionality. You can find the current running process and information as to their owners by running the "ps" command. This command is universal among Linux and Unix systems. Below is a quick tutorial on how to use GDB and the "attach" command to break into a running process and debug. I found this tutorial among many via a Google search.

Debug a Running Process

I hope this helps you out.
Asa Kirby
CompactRIO Product Marketing Manager
________________
Sail Fast!
0 Kudos
Message 8 of 8
(3,946 Views)