Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Using DLL with Cocoa
- Thread starter satyam90
- Start date
- Sort by reaction score
robbieduncan
Moderator emeritus
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.
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.
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.
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
macrumors 68040
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.
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.
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
macrumors 601
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.
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?
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
macrumors 6502a
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.
Cromulent
macrumors 604
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.
