macOS Using DLL with Cocoa

[satyam90]

Hi,
I am creating a DLL with some functionality.
How to use the this DLL with my Cocoa code. How to include it with my build and use the functions available in DLL in my code.
Any suggestions will be appreciated.
Regards,
Satyam.

 

[robbieduncan]

You cannot use a dll on a Mac. dlls are Windows only.

 

[satyam90]

So what will be the solution for DLL's on Mac.
But through Make files, I am able to build DLL's, But I am now knowing how to use it.

 

[garethlewis2]

You can't build a DLL with OS X. They only exist in the Windows world.

On OS X you have several contributing equivalents. From a purely Unix view you have the simple .a and .so formats. .a is just a static library that will be linked into your code at compile time. .so is a dynamic library that is linked into your applicaiton by the linker at runtime. From a more OS X view you can build a Framework.

There are plenty of tutorials on doing this. Google will be your bestest friend in the whole world with problems like this.

 

[satyam90]

But I am making dll the same way I am creating on Windows using Cygwin. And the DLL is getting created in Mac also. How can it be possible?
On browing the net using google, I found "dylib" is an alternative of DLL on Mac. instead of using .a or .so, can i use "dylib" files.

 

[MongoTheGeek]

But I am making dll the same way I am creating on Windows using Cygwin. And the DLL is getting created in Mac also. How can it be possible?
On browing the net using google, I found "dylib" is an alternative of DLL on Mac. instead of using .a or .so, can i use "dylib" files.

Yes you can use dylib's.

You may want to rethink your approach though. Having dynamically linked libraries aside from the system frameworks can lead to bugs. Plus Mac users don't expect installers. Honestly I don't trust them. I love being able to open a dmg and drag the app to install it. Then drag it away and know that its gone.

 

[garethlewis2]

It doesn't really matter if the program you are using creates the binary equivalent of a DLL. VLC and MPlayer both use hackery to load windows DLLs that process film, but they can't directly use these DLLs. The same is true with the DLL your program creates. It is useless in OS X.

dylib is just the name of the dynamic linker that loads and also builds shared libraries.

You need to search on how to create an archive using gcc.

If the code you have been comes from a project on Windows and it requires a DLL you are in a seriously bad situation. Windows users don't expect to load an Apple app say like iMovie and expect it to work since the underlying hardware is identical.

Here is how to to build both a static and shared version of some example code

int add_0(int number) {
return (number + 0)
}

This is in a file called src0.c You could also create src1.c through to scr5.c that do the same thing but add a different value.

cc -g -c src*.c

This will create 5 src*.o files

ar crl libaddnum.a *.o

This creates the archive libaddnum.a, but it can't be used yet as there is no index.

ranlib libaddnum.a. You now have a working library that you will link against at compile time. This is the old fashioned way as the library when compiled against your program will be added the resulting binary. If the library was say 1024mbytes and you had 10 programs using that binary, they would together consume 10 gigs of HD space with no apparent performance boost.

Here is how to do the same task with shared libs

ld -dynamic -o libaddnum.dylib *.o

cc -g useprog.c libaddnum.dylib

The dynamic lib libaddnum is now linked at runtime and is not part of the programs size. So say like the previous example, if the library was 1024mbytes and you had 10 programs. The resulting space would be 1100mbytes. A saving of 10 fold.

If this doesn't help you, then you really need to get a book on building shared libs in Unix.

 

[Krevnik]

Yes you can use dylib's.

You may want to rethink your approach though. Having dynamically linked libraries aside from the system frameworks can lead to bugs. Plus Mac users don't expect installers. Honestly I don't trust them. I love being able to open a dmg and drag the app to install it. Then drag it away and know that its gone.

I agree very much with this comment. While there is a lot of good information, if your Mac application is an app bundle, you REALLY should look into how to build a Framework on the Mac. It is possible to do it from a makefile with some tweaking, or you can setup an xcodeproj to build the framework from the same source files.

 

[kgoyal15]

will it work on MAC OS X

Hi there,
the dynamic library that is created (libaddnum.dylib), will it work on MAC OS or it is for cygwin on windows only?

 

[yeroen]

Hi there,
the dynamic library that is created (libaddnum.dylib), will it work on MAC OS or it is for cygwin on windows only?

No. Windows, OS X, and Linux have completely different native executable and object formats (PE, Mach-O, and ELF respectively). You can't move libraries across systems without (at least) a recompile any more than you can move whole programs.

 

[kgoyal15]

No. Windows, OS X, and Linux have completely different native executable and object formats (PE, Mach-O, and ELF respectively). You can't move libraries across systems without (at least) a recompile any more than you can move whole programs.

Can I compile the whole program on
Windows and runs on MAC OS

 

[yeroen]

Not without (at the very least) cross compiling. If you have to ask, you probably shouldn't be doing it.

 

[Cromulent]

Can I compile the whole program on
Windows and runs on MAC OS

No. As previously stated it would require at least a recompile. If you have used windows only APIs then those parts will need to be rewritten as well.

 

[cmaier]

Wow.