Creating Labview callable DLLs on OSX

[ShaunR]

Hi all.

Not really a "Labview" question....but related.

I've "zero" experience with Macs so apart from a huge learning curve, I'm getting bogged down with multiple tool chains and a severe lack of understanding of MAC (which I think is BSD based).

I've released an API which currently supports windows (x32 and x64) and has been reported to work with Linux x32. These work because I'm able to compile dll and .so for those targets. I'd really like to include Mac in the list of support but am having difficulty compiling a shared library (dynlib?) that Labviewwill accept.

I have set up a Mac OSX Leopard 1.5 virtual machine with labview and Code:Blocks.It all runs (very slowly) but I'm able to compile a shared library in both x32 and x64 (Well. I think I can at least.. The gcc compiler is using -m32 for the 32 bit and won't compile if I have the wrong targets). The trial version of Labview I downloaded I know is 32 bit (got that from conditional disable structure) and I think the Mac is 64 bit.

So I have the tool-chains set up and can produce outputs which I name with a "dynlib" extension. However. No matter what compiler options I try, whenever I try to load a successful build using the labview library function (i.e. select it in the dialogue) it always says it's "Not a valid library".

Does anyone know what the build requirements (compiler options, architecture, switches etc) are for a Mac shared library? There are a plethora of them and I'm really in the dark as to what is required (i386?, Intel?, AMD? all of the above?, -m32?, BUILD_DLL?, shared?)

Any help would be appreciated.

[ChS]

On OSX, LV expects to interface a ".framework" file. It has to be 32 bits as LV on OSX is still 32 bits.

The easiest way to produce a framework is to use XCode and select new project / carbon or cocoa framework.

XCode will prepare a skeleton ready to be used.

As SQLite is built-in OSX, you should use the provided implementation and just write a wrapper around it.

It is located in /usr/lib/sqlite3. This wrapper is only a few lines of code I've done similar wrappers for other libs.

Let me know if you'd like to have a copy of the XCode project and files.

Note that LV does not unload DLL/framework from memory. You have to quit LV. If anyone found an alternative I'm very much interested!

Chris

Edited November 8, 2010 by ChS

[ShaunR]

On OSX, LV expects to interface a ".framework" file. It has to be 32 bits as LV on OSX is still 32 bits.

The easiest way to produce a framework is to use XCode and select new project / carbon or cocoa framework.

XCode will prepare a skeleton ready to be used.

As SQLite is built-in OSX, you should use the provided implementation and just write a wrapper around it.

It is located in /usr/lib/sqlite3. This wrapper is only a few lines of code I've done similar wrappers for other libs.

Let me know if you'd like to have a copy of the XCode project and files.

Note that LV does not unload DLL/framework from memory. You have to quit LV. If anyone found an alternative I'm very much interested!

Chris

Many thanks Chs.

I too thought about using the pre-installed SQLite. But I'm not sure that I can guarantee that it will be 32 bit if the Mac starts in 64 bit mode. A wrapper is not a useful way forward as it requires upkeep of other code than Labview and would require a lot of work re-implementing an interface which is already there. A windows wrapper went this route and its limited because of this.

From my limited reading of the "framework" implementation its a bit like a fat arch. So does that mean I can compile a 32 bit and 64 bit and include both in the framework? Does the pre-installed SQLite have both 32 bit and 64 bit and switch transparently? Do I really have to type in each and every function rather than select it from the LV combo-box? (And does that mean I select the ". framework" instead of the dylib?) There seems to be little information on the net for Mac developers.

I will have a play with Xcode. I know its installed but not sure where to find it (doesn't show up under applications). I've only just learnt to use CodeBlocks so naively though it would just be a case of re-compiling for the Mac (its also available for the Mac)

Edited November 8, 2010 by ShaunR

[ChS]

> I too thought about using the pre-installed SQLite. But I'm not sure that I can guarantee that it will be 32 bit if the Mac starts in 64 bit mode. A wrapper is not a useful way forward as it requires upkeep of other code than Labview and > would require a lot of work re-implementing an interface which is already there. A windows wrapper went this route and its limited because of this.

> From my limited reading of the "framework" implementation its a bit like a fat arch. So does that mean I can compile a 32 bit and 64 bit and include both in the framework? Does the pre-installed SQLite have both 32 bit and 64 bit

> and switch transparently? Do I really have to type in each and every function rather than select it from the LV combo-box?

XCode will generate 32/64bit framework. I did not check it but I'm pretty sure the dylib is 32/64 bit. Anyway LV on the Mac is still 32 bit.....

And yes you will have to reselect the correct the lib and function name in you CLN. You could specify the lib name as a parameter of the CLN instead.

> (And does that mean I select the ". framework" instead of the dylib?) There seems to be little information on > the net for Mac developers.

Yes select "YourSQLite3.framework" in the CLN. Be carefull since LV does not unload it, you have to quit LV to load a new version!

> I will have a play with Xcode. I know its installed but not sure where to find it (doesn't show up under applications).

Its in /Developer/ or you may need to download the latest version from Apple.

> I've only just learnt to use CodeBlocks so naively though it would just be a case of re-compiling for the Mac (its also > available for the Mac)

It should work as long as it is able to generate frameworks.

ChS

[ShaunR]

> I too thought about using the pre-installed SQLite. But I'm not sure that I can guarantee that it will be 32 bit if the Mac starts in 64 bit mode. A wrapper is not a useful way forward as it requires upkeep of other code than Labview and > would require a lot of work re-implementing an interface which is already there. A windows wrapper went this route and its limited because of this.

> From my limited reading of the "framework" implementation its a bit like a fat arch. So does that mean I can compile a 32 bit and 64 bit and include both in the framework? Does the pre-installed SQLite have both 32 bit and 64 bit

> and switch transparently? Do I really have to type in each and every function rather than select it from the LV combo-box?

XCode will generate 32/64bit framework. I did not check it but I'm pretty sure the dylib is 32/64 bit. Anyway LV on the Mac is still 32 bit.....

And yes you will have to reselect the correct the lib and function name in you CLN. You could specify the lib name as a parameter of the CLN instead.

> (And does that mean I select the ". framework" instead of the dylib?) There seems to be little information on > the net for Mac developers.

Yes select "YourSQLite3.framework" in the CLN. Be carefull since LV does not unload it, you have to quit LV to load a new version!

> I will have a play with Xcode. I know its installed but not sure where to find it (doesn't show up under applications).

Its in /Developer/ or you may need to download the latest version from Apple.

> I've only just learnt to use CodeBlocks so naively though it would just be a case of re-compiling for the Mac (its also > available for the Mac)

It should work as long as it is able to generate frameworks.

ChS

OK. So I think you are saying that frameworks are the key and there's no such thing as a dylib in isolation (at least as far as Labview is concerned).

The problem I've come up against now is that I haven't been able to load ANY frameworks with Labview. Even those already installed with the Mac.

I managed to find the SQLite framework (its under TCL). Couldn't load that, maybe because its is compiled with the TCL interface (usual "not a valid library" error). I'm not familiar with TCL so don't know if that's the issue or just the fact that I cannot load frameworks full stop.

Bit of a newbies question. But.........

I can create a bare-bones framework structure using Xcode. And I can create a dylib with Codeblocks. I can also get it to copy the dylib to the framework. But under what do I add it to? Resources? Target? The framework seems geared towards distribution of applications and any tutorials I am able to find all talk about how to link the executable to the framework All I need is a wrapper for the dylib to get Labview to load it.

Like most things new to me. I tend to ask a lot of "silly" questions until I arrive at a "Eureka" moment when I am am able to visualise how everything fits together. At the moment I can see what I want. Have a some of the pieces needed to get to what I want, But don't know if I have all the pieces. Have the wrong pieces or Labvew is just being obstinate. Do you have an Xcode example of one that you made yourself using a dylib that Labview likes?

I've attached the dylib I've created. Perhaps you could wrap it so I can see how it all fits together?

Edited November 11, 2010 by ShaunR

[ChS]

OK. So I think you are saying that frameworks are the key and there's no such thing as a dylib in isolation (at least as far as Labview is concerned).

You are correct LV CLN only recognized "framework"

The problem I've come up against now is that I haven't been able to load ANY frameworks with Labview. Even those already installed with the Mac.

I managed to find the SQLite framework (its under TCL). Couldn't load that, maybe because its is compiled with the TCL interface (usual "not a valid library" error). I'm not familiar with TCL so don't know if that's the issue or just the fact that I cannot load frameworks full stop.

This is strange, there are plenty of frameworks that you can link to, try carbon framework. Anyway LV VIs are often calling frameworks. To see an example check /vi.lib/Platform/Miscellaneous.llb/TickCount.vi

Bit of a newbies question. But.........

I can create a bare-bones framework structure using Xcode. And I can create a dylib with Codeblocks. I can also get it to copy the dylib to the framework. But under what do I add it to? Resources? Target? The framework seems geared towards distribution of applications and any tutorials I am able to find all talk about how to link the executable to the framework All I need is a wrapper for the dylib to get Labview to load it.

Like most things new to me. I tend to ask a lot of "silly" questions until I arrive at a "Eureka" moment when I am am able to visualise how everything fits together. At the moment I can see what I want. Have a some of the pieces needed to get to what I want, But don't know if I have all the pieces. Have the wrong pieces or Labvew is just being obstinate. Do you have an Xcode example of one that you made yourself using a dylib that Labview likes?

See the attached file. I've made a basic wrapper that call sqlite3 functions. It links against the OSX version of SQlite 3 using the OTHER_LDFLAGS = -lsqlite3 in the linker options for the selected target.

I have also modified the low level vis to include the OSX calls. See the provided All_OSX.vi to have a direct link to the modified VIs.

I DID NOT DO CHECK SQLite PARAMETERS, you should not use the VIs as is, but carefully check that the c and LV code are in adequacy!

I've attached the dylib I've created. Perhaps you could wrap it so I can see how it all fits together?

In the terminal doing a > nm SQLite3x32_dylib show that you did not export the sqlite3 symbols!

Note that LV does not unload a framework, you have to quit LV to reload the framework, this is quite painful if you don't have an SSD.

Hope this help

ChS

LV_SQLite_v001.zip

[ShaunR]

Fantastic.

Many, Many thanks. I really appreciate it.

You examples didn't work straight out of the box. But I re-compiled the framework with i386 rather than x64 and labVew now accepts it and I can run your dll verson vi.

I found another framework that Labview could load in the /development/frameworks. There are 3 examples located in there. 1 I can load. the others I cannot. After getting yours to work it it must be due to the bitness (although I'm not sure how to check).

Thanks to your example, I've compiled a framework with sqlite 3.7.3 successfully (lots of warnings though) and your re-hashes of my low-level VIs seem fine. I have a rough idea how things fit together now and I think I should be able to compile a framework without the intermediary LV_SQlite wrapper.

Looks like I'm going to be very unsociable tomorrow whilst I play with the Xcode settings

I'll let you know how I get on later in the week. Muchos Grassy Arse

[ChS]

Fantastic.

Many, Many thanks. I really appreciate it.

You examples didn't work straight out of the box. But I re-compiled the framework with i386 rather than x64 and labVew now accepts it and I can run your dll verson vi.

I guess it depends on the XCode and OS version you are using. There is an option to tell XCode to build for all format (i386,x64 and PPC)

You may also links against various OS version. I usually do build for 10.5 SDK.

I found another framework that Labview could load in the /development/frameworks. There are 3 examples located in there. 1 I can load. the others I cannot. After getting yours to work it it must be due to the bitness (although I'm not sure how to check).

Bitness? unless you have installed the SDK for 10.4 you should not have a bitness issue.

Thanks to your example, I've compiled a framework with sqlite 3.7.3 successfully (lots of warnings though) and your re-hashes of my low-level VIs seem fine. I have a rough idea how things fit together now and I think I should be able to compile a framework without the intermediary LV_SQlite wrapper.

The wrapper was needed since I (ok the OS) dynamically call the built in OSX version of sqlite using the -lsqlite3 in the linker flag. I had to rename calls to avoid conflict.

This limit will go away if you compile the source for sqlite3.

Looks like I'm going to be very unsociable tomorrow whilst I play with the Xcode settings

There are many to play with. I'm far for mastering all of them....

I'll let you know how I get on later in the week. Muchos Grassy Arse

I'm looking forward to see it

Chris

[ShaunR]

I guess it depends on the XCode and OS version you are using. There is an option to tell XCode to build for all format (i386,x64 and PPC)

You may also links against various OS version. I usually do build for 10.5 SDK.

Yup. Still trying to get my head around all the compiler options (haven't even looked at linker stuff yet). Some compile, some don't.

Bitness? unless you have installed the SDK for 10.4 you should not have a bitness issue.

I've got them all installed I'm trying to compile against 10.4, 10.5, 10.6. Sometimes they won't compile at all depending on certain settings. I need to be able to figure out the minimum version since I won't have the luxury of just getting it to work on my system alone (looks like I'll have to install a few more Mac versions)

The wrapper was needed since I (ok the OS) dynamically call the built in OSX version of sqlite using the -lsqlite3 in the linker flag. I had to rename calls to avoid conflict.

This limit will go away if you compile the source for sqlite3.

Indeed. I'm in two minds about this. I would like to compile from source. But at the moment the debug is 5MB and a release is 2.4MB

There are many to play with. I'm far for mastering all of them....

I'm looking forward to see it

Chris

Xcode is not very intuitive and as soon as I figure out how and what it's doing..... will ditch it in favour of something else. In theory, we shouldn't need it at all since the Mac version of SQLite has all the scripts etc to build and install it.But I don't know what half the files are for (yet). It's a steep learning curve having never used a Mac before (just finding stuff takes me 1/2 an hour...lol). But getting there

[ChS]

SQLite converter

This might of interest to someone with mySQL, PostgreSQL or Oracle database

http://www.sqlabs.co...teconverter.php

ChS