Call library function node and .dylib

[xavier30]

Dear Lava users

(im sorry if this post is more a c/c++ code porting problem than a actual labview problem, but... )

I just bought myself a brand new apple Mac book Pro, 15" with OS X Leopard (10.5.X i think?) installed.

After playing around and familiarizing my self with mac, OS X and its unix like environment, i decided to port some of my labview code wrappers that we use at work to interface with various things, previously compiled for both windows in visual studio 6 and 8 and linux red hat 4 and 5. (gcc 3.4.2 and gcc 4.1.2 i beleive, but not 100% sure).

So i did some reading, and it seemed that on mac a ".dll" from windows and ".so" from unix/linux on OS X is called ".dylib". i installed the Xcode package, labview 8.6 for mac, and some other stuff that might come in handy.

After modifying my makefiles (basically replasing -shared with -dynamiclib and recompiling with gcc in the terminal) i tried to load the new "myFile.dylib" in labview.

Unfortunately labview didn't read any of my callbacks, and the dropdown list where you can choose function in the "call library node" was grayed out or empty.

so not knowing what whent wrong i made a small "cout" callback like this:

############# myCout.cpp #################

#include <iostream>

#define API __attribute__(( __cdecl__ ))

extern "C" void API Cout(char * myCout)

{

std::cout << myCout << std::endl;

}

################ Makefile #################

CC = g++

# Backup files from various editors ...

BAKS = ,* *~ *.bak *.BAK .es1* .B* %*% .ec1 .ek1 .*~ core a.out *JNL *.lst \\\#*\\\# .nfs* *%

#

CFLAGS = -g -c -I/usr/include -o $@

LDFLAGS =

OBJ =

LDLIBS =

#

all: cout.so

#

cout.so: cout.o

@-$(RM) $@ $(W)$@

$(CC) $^ $(LDLIBS) -o $@ -dynamiclib //only changed this on mac

#

cout.o: cout.cpp

$(CC) $(CFLAGS) cout.cpp

#

clean:

$(RM) *.o $(BAKS)

making the .dylib went fine. no errors, and no warnings. but still I'm unable to load this library and use its function in LabVIEW.

What am i doing wrong??

Any help would be highly appreciated.

X

Update: I realized after some searching that i can't use "dylib" in mac, but have to use something called ".framework" (bear with me cos this is all new to me ) so then i hoped all i had to do was replacing the "-dynamiclib" with "-framework" and name the output xxx.framwork, but now it won't compile (said something about "argument to -Xlinker missing" )

guess it's time for bed and try with some fresh eyes tomorrow.

[Rolf Kalbermatter]

QUOTE (xavier30 @ Dec 16 2008, 06:47 PM)

Dear Lava users

(im sorry if this post is more a c/c++ code porting problem than a actual labview problem, but... )

I just bought myself a brand new apple Mac book Pro, 15" with OS X Leopard (10.5.X i think?) installed.

After playing around and familiarizing my self with mac, OS X and its unix like environment, i decided to port some of my labview code wrappers that we use at work to interface with various things, previously compiled for both windows in visual studio 6 and 8 and linux red hat 4 and 5. (gcc 3.4.2 and gcc 4.1.2 i beleive, but not 100% sure).

So i did some reading, and it seemed that on mac a ".dll" from windows and ".so" from unix/linux on OS X is called ".dylib". i installed the Xcode package, labview 8.6 for mac, and some other stuff that might come in handy.

After modifying my makefiles (basically replasing -shared with -dynamiclib and recompiling with gcc in the terminal) i tried to load the new "myFile.dylib" in labview.

Unfortunately labview didn't read any of my callbacks, and the dropdown list where you can choose function in the "call library node" was grayed out or empty.

so not knowing what whent wrong i made a small "cout" callback like this:

############# myCout.cpp #################

#include <iostream>

#define API __attribute__(( __cdecl__ ))

extern "C" void API Cout(char * myCout)

{

std::cout << myCout << std::endl;

}

################ Makefile #################

CC = g++

# Backup files from various editors ...

BAKS = ,* *~ *.bak *.BAK .es1* .B* %*% .ec1 .ek1 .*~ core a.out *JNL *.lst \\\#*\\\# .nfs* *%

#

CFLAGS = -g -c -I/usr/include -o $@

LDFLAGS =

OBJ =

LDLIBS =

#

all: cout.so

#

cout.so: cout.o

@-$(RM) $@ $(W)$@

$(CC) $^ $(LDLIBS) -o $@ -dynamiclib //only changed this on mac

#

cout.o: cout.cpp

$(CC) $(CFLAGS) cout.cpp

#

clean:

$(RM) *.o $(BAKS)

making the .dylib went fine. no errors, and no warnings. but still I'm unable to load this library and use its function in LabVIEW.

What am i doing wrong??

Any help would be highly appreciated.

X

Update: I realized after some searching that i can't use "dylib" in mac, but have to use something called ".framework" (bear with me cos this is all new to me ) so then i hoped all i had to do was replacing the "-dynamiclib" with "-framework" and name the output xxx.framwork, but now it won't compile (said something about "argument to -Xlinker missing" )

guess it's time for bed and try with some fresh eyes tomorrow.

Not sure exactly about the details at the moment, but first the *.framework is not a file but a directory on the Mac. It contains various files that implement the actual shared library in a fairly clean versioned manner.

If you want to see an example of how it is doen you can go and checkout the lvzip sources from the OpenG Toolkit on sourceforge. There is an XCode project contained to compile the various sources into a MacOS framework.

Rolf Kalbermatter

[xavier30]

QUOTE (rolfk @ Dec 18 2008, 10:09 AM)

Not sure exactly about the details at the moment, but first the *.framework is not a file but a directory on the Mac. It contains various files that implement the actual shared library in a fairly clean versioned manner.

If you want to see an example of how it is doen you can go and checkout the lvzip sources from the OpenG Toolkit on sourceforge. There is an XCode project contained to compile the various sources into a MacOS framework.

Rolf Kalbermatter

Thanks Rolf

This world of Mac is still new to me

After making this post, i managed to make a small Xcode project and creating the .framework "directory" and making use of some simple callbacks.

My only "problem" now seems to be how i can re-use my makefile in the mac unix environment. I guess this post is more suited in the mac/linux forums, but i'll post back what i figure out.

X

[Rolf Kalbermatter]

QUOTE (xavier30 @ Dec 18 2008, 08:49 AM)

Thanks Rolf

This world of Mac is still new to me

After making this post, i managed to make a small Xcode project and creating the .framework "directory" and making use of some simple callbacks.

My only "problem" now seems to be how i can re-use my makefile in the mac unix environment. I guess this post is more suited in the mac/linux forums, but i'll post back what i figure out.

I can't help you with that. Makefile creation is a rather tricky business even if you only want to target one OS. Cross platform is simply beyond my knowledge. The way I do it is using MS VC .dsw project files for Windows, simple Makefile for Linux, Xcode project file for Macintosh and last but not least a modified Unix Makefile.vxworks for VxWorks creation. Trying to figure out the perfect settings and everything to create a cross platform Makefile is a noble desire but I have better things to do with my time ;-)

Rolf Kalbermatter

[Guhan Senthilkumar]

Hi Xavier,

 

I am new to mac as well.

I am facing the same problem as you faced before.

 

I have created a small .dylib written in C++ and i tried to use with the call library node.

After reading your post I figured .dylib cant be used and framework is the only option.

 

My question is how do i create a c++ framework using xcode 4.6.3? or using any xcode versions.

If i go through the normal template option for creating a framework I get .m files and I have no idea what to do with them.

Please help me on this

 

Guhan 

 

 

[ShaunR]

Hi Xavier,

I am new to mac as well.

I am facing the same problem as you faced before.

I have created a small .dylib written in C++ and i tried to use with the call library node.

After reading your post I figured .dylib cant be used and framework is the only option.

My question is how do i create a c++ framework using xcode 4.6.3? or using any xcode versions.

If i go through the normal template option for creating a framework I get .m files and I have no idea what to do with them.

Please help me on this

Guhan

You must be using LV2011 or below.

I came to the conclusion (rightly or wrongly) that dylib support was an incremental development on the Mac with the dialogue one step behind.

LV2010 and below cannot use dylibs at all (the library won't load). In Labview 2011, you cannot choose them from the drop down in the CLFN (must be Framework), but they do work, So if you create the call in 2012 and back-save or type the path and function name in;, it will be fine (the library will load).

2012 and later are fine and you can select them in the drop-down..

Edited September 3, 2013 by ShaunR

[JackDunaway]

You must be using LV2011 or below.

I came to the conclusion (rightly or wrongly) that dylib support was an incremental development on the Mac with the dialogue one step behind.

LV2010 and below cannot use dylibs at all (the library won't load). In Labview 2011, you cannot choose them from the drop down in the CLFN (must be Framework), but they do work, So if you create the call in 2012 and back-save or type the path and function name in;, it will be fine (the library will load).

2012 and later are fine and you can select them in the drop-down..

 

It appears that in LV2015 LabVIEW does not populate the drop-down with exported functions, but "everything works" if you manually set it up.

 

In other words, you can type or paste into the `Function name` box on the configuration window and the code executes as expected -- you just miss the UI affordance of that cozy feeling seeing the drop-down arrow go from disabled to enabled once pointing to the library, and the type-ahead autofill for function names.

Additionally, `*.dylib` is not recognized as the shared library type on OS X. 

[ShaunR]

It appears that in LV2015 LabVIEW does not populate the drop-down with exported functions, but "everything works" if you manually set it up.

 

In other words, you can type or paste into the `Function name` box on the configuration window and the code executes as expected -- you just miss the UI affordance of that cozy feeling seeing the drop-down arrow go from disabled to enabled once pointing to the library, and the type-ahead autofill for function names.

Additionally, `*.dylib` is not recognized as the shared library type on OS X. 

OS-X-dylib.png

 

That's progress No one uses Mac anyway

 

On a more serious note: I'm not sure what you mean its not recognised.

Edited August 16, 2015 by ShaunR

[JackDunaway]

I'm not sure what you mean its not recognised.

 

Referring to the screenshot where `libstringtools.dylib` is greyed and disabled when the LabVIEW dialog filters only files of type "Shared Libraries". When the filter is changed to "All Documents" (i.e., any filetype), the shared library becomes un-greyed.

 

 

Additionally, `*.dylib` is not recognized as the shared library type on OS X. 

 

This was worded poorly, making it sound like the bug is in OS X. In this dialogue, LabVIEW apparently only considers `.framework` filetypes as being a "Shared Library", but not `.dylib` filetypes.

[Rolf Kalbermatter]

Referring to the screenshot where `libstringtools.dylib` is greyed and disabled when the LabVIEW dialog filters only files of type "Shared Libraries". When the filter is changed to "All Documents" (i.e., any filetype), the shared library becomes un-greyed.

 

 

 

This was worded poorly, making it sound like the bug is in OS X. In this dialogue, LabVIEW apparently only considers `.framework` filetypes as being a "Shared Library", but not `.dylib` filetypes.

 

.dylib is basically the actual shared library file that contains the compiled object code. It is similar to the .so file on Linux but in a different object format. .framework is a package very much like the .app for an application. It is a directory structure containing several symlink files pointing over a few redirections to the actual binary object file that is the shared library. In addition it can contain string and other resource files for localization and version information. The low level shared module loader works with the .dylib file or the binary object file inside the .framework, but the MacOSX shared library support works on the .framework level, alhough it does crrently still support to load .dylibs directly too. But Apple tries to move everyone to the package format and removes more and more references in the documentation about the low level access and there is a good chance that support for that is eventually depreciated.

 

This is all in an attempt to remove unportable interfaces from the application level in order to make an application work more an more likely on any iOS compatible device.