Importing shared Library .so in Linux.

[Yaw Mensah]

I have created a simple shared library with an add function. When I try to call it with the Call Library Function Node, it always change the name, e.g. add() to Z2addii(). 

In the Error is always the same error. Call Library Function Node 'libtestshared.so.Z2addii: not found in library.

When i change the functionname in the shared library to Z2addii the Call Library Function Node then calls the Z3Z2addiiii. 

But when i compiler a c-programm which uses the shared library i get the desired output.

I will be grateful for suggestions.

[Mefistotelis]

Read this:

https://en.wikipedia.org/wiki/Name_mangling

 

Symbols are decorated this way only in C++. If you just don't want the decoration, compile with C compiler, or use `extern "C" {` and declare your functions within that block.

 

For how LabVIEW handles name mangling - someone who knows LV would have to reply.

 

 

[Yaw Mensah]

Thank you very much. Call Library Function Node doesn't change the name and calls the fuctions as desired.

[Rolf Kalbermatter]

LabVIEW doesn't handle name mangling at all. It would be an exercise in vain to try since GCC does it differently than MSVC, just to name two. There is no standard in how names should be mangled and each compiler uses its own standard.

There is some code in LabVIEW that tries to work around some common decorations to functions names such as a prepended underscore. If the Call Library Node can't find a function in the library it tries to prepend an underscore to the name and tries again. Stdcall compiled functions also have by default a decoration at the end of the functions name. It is an ampersand (@) followed by a number that basically indicates the number of bytes that have to be pushed on the stack for this function call. LabVIEW tries to match undecorated names to names with the stdcall decoration if possible but that can go wrong if you have multiple functions with the same name but differently sized parameters. It's also not possible to compile that in standard C but C++ could theoretically do it, but I never saw it in the wild until now.

One other speciality that LabVIEW does under Windows is if a function name is only a decimal number and nothing else. In that case it interprets the name as ordinal number and calls the function through its ordinal number. This is an obscure Windows feature that is seldom used nowadays but Windows does have some undocumented functions that are only exported by an ordinal number. Every exported function has an ordinal number, but not every exported function does need an exported function name. This was supposedly mostly to save some executable file size, since the names in the export table can mount up to shockingly many kB's of data.

What the OP describes seems to be some of these algorithms trying to match a non-existing function name to one which is present in the library, going somehow havoc.

Edited January 30, 2021 by Rolf Kalbermatter