Using .so libraries under Mac

[maverick_pol]

Hi,

I would like to ask, can I use .so library files under mac ?
I have compiled one library(OGDI) under linux. Is macx and unix may use the same lib files? is linking done the same way?

For example,

When I write this code for linux(in the .pro file):



LIBS += -L /ogdi/lib/linux -logdi -lvrf -l.....

can I do the same for mac?

I am asking as I have a strange linking problem:
"/usr/bin/ld -L : directory name missing" when I use the same code in the .pro for mac as for linux.

Thank you for any help.

[Thomas]

Short answer: you cannot use libraries compiled for OS Foo with OS Bar. So, no, you cannot reuse Linux libraries for MacOS.

Log story: this heavily depends on the OSes' ABI - Application Binary Interface. They are dependent on the OS type (Linux, Solaris, BSD, etc.) and and the CPU for which the code has been compiled (PowerPC, Sparc, IA32). An easy way to find out if your OS can handle libraries which have been compiled for other OSes is to the program file with the library in question:

thomas@mac ~ $ file /lib/libpthread-2.6.1.so
/lib/libpthread-2.6.1.so: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.6.9, stripped
thomas@mac ~ $ file /mnt/fw/win/windows/system/mfc42.dll
/mnt/fw/win/windows/system/mfc42.dll: MS-DOS executable PE for MS Windows (DLL) (GUI) Intel 80386 32-bit

The output will tell you for which CPU/architecture the executable/library had been compiled and for which OS, i.e. ABI.

[maverick_pol]

Ok, that explains a lot. Thanks

So what does this mean:

libproj.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

2 Questions more:

1) so if I want to use a library uner mac I have to compile it under mac(talking about the same processors)
2) what are libraries extensions under mac? I see ".a" is this the only possible lib extension? Is it possible to compile a library and have .so files?

I understant that these questions are quite newbie'like, but please be patient : ) Thanks.

Thanks.

Maverick

P.S.

one more:
3) While linking libs under mac, is this ok:

LIBS+= -L path_to_libs -lfristLib -lndLib.... ?

[wysota]

Furthermore ABI also depends on the compiler used, so even on the same platform you can't use a library if it was compiled with an incompatible compiler.


1) so if I want to use a library uner mac I have to compile it under mac(talking about the same processors)
Yes. And you have to compile it with the same family of compilers (GCC probably) and the same architecture (you can't use a PPC library with an Intel application or 64b library with a 32b app).


2) what are libraries extensions under mac?
".dylib"


3) While linking libs under mac, is this ok:

LIBS+= -L path_to_libs -lfristLib -lndLib.... ?

Yes, it's fine.

[maverick_pol]

Thanks...so..

I have compiled the ogdi with gcc 4.0 and I am using the same gcc 4.0 under mac 10.4.
I have compiled Qt under Linux to use linux-g++ mkspec and compiled Qt under Mac to use the macx-g++ (in both cases using the same gcc version). What is more I am working on the same processor(machine).

So, just to be 100% sure, I can't use the same .so libs(compiled under linux, on Mac?) ? yes?

Secondly, ".dylib" are libs on Mac and what about ".a"? Is ".a" also a lib extension? Or, ".dylib" is the only lib ext.?

I do appreciate your understanding and patientce. I am new to Mac system and need some basic knowledge.

Beforehand thank you!

Kacper

[wysota]

So, just to be 100% sure, I can't use the same .so libs(compiled under linux, on Mac?) ? yes?
Correct.


Secondly, ".dylib" are libs on Mac and what about ".a"? Is ".a" also a lib extension? Or, ".dylib" is the only lib ext.?

.a is a static library ("archive").

[Thomas]

Correct.



.a is a static library ("archive").

Let me give a more detailed explanation since you mentioned you are a newbie. :)

.a libraries are files which contain compiled code in an archive format. Under Linux/Unix the program ar is used to create those. Extracting a .a library gives you .o files (compiled files, object files, binary, not executable). Each .o file is the result of a single compilation (which can contain multiple source files) like "gcc -c -o myStuff.o foo.c bar.c". You would link against a .a library libfoo.a if your code shall be self sufficient in respect to code in libfoo.a which means that it should not depend on a library libfoo.so on the platform where your application runs. This can have several reasons. Eittther you are not allowed to distribute the ldynamic version of the library or your company restricts distributed binaries to be single files only. Your application would then contain all the parts (.o files) of libfoo.a which your application needs. GCC takes care of this process when your application is linked together.

.dylib on MacOS or .so files are libraries which contain essentially the same code which a static library would contain. The difference is that these libraries will be loaded by the system's dynamic library loader as soon as your application is executed. The dynamic library loader checks if your application is linked against certain libraries (at link time you specify -lfoo, really just a place holder) and looks in the dynamic library on the system for methods, functions, classes, variables, etc. which are missing in your application but in the library and makes them available to the application. The benfit is here that multiple applications can reuse the same library. This makes maintenance very easy and saves tons of space.