Can a static library (.a) compiled in Mac OS work in Linux? Do archives in Mac OS and Linux have the same format?
Can a static library (.a) compiled in Mac OS work in Linux?
Yes, but only if you use cross-compiler to compile object files that you'll put into that library.
Do archives in Mac OS and Linux have the same format?
It is very likely that the format of .a archive files is the same between Linux and Mac OSX (I have not verified this, but most UNIX systems use the format referenced above), but that isn't going to help you: the archive library is little more than a concatenation of .o files with some indices, and .o files themselves are different between Linux (ELF object file format) and Mac OSX (Mach-O object file format).
The Linux linker will have no trouble looking inside the .a, but it will ignore any non-ELF files it finds there.
Which Linux? Linux is compiled for many CPU architectures. Macs are currently x86-only.
As others mentioned, Macs use the Mach-O executable format, while Linuxes usually use ELF, and the way syscalls are handled and which libraries are available are completely different.
So in practice, on out-of-the-box systems, there may be similarities, but it's unlikely anything will run.
Question is: What are you trying to do?
There are ways (like http://www.darlinghq.org) to make executables from one platform run on the other, by adding code that performs an on-the-fly translation and implementing the missing libraries.
There may also be a way to create a .a file that contains executables for several platforms, so compilers will pick the right one and ignore the other. If you used a cross-compiler, you could probably build a .a on a Mac that contains code compiled for a Linux.
Related
I have developed a project in language C on ubuntu 12.04 and I have some shared-object libraries (.so files). Now I want to use that libraries on freeBSD 8.3 OS. Is this possible? If not how can I do that? Is that necessary to compile my source files on freeBSD?
Andras is talking about running Linux binaries. You are talking about using Linux shared libraries (presumably with programs that are compiled on FreeBSD). That's an entirely different thing.
It's potentially possible to run some fairly limited set of Linux binaries on FreeBSD because the FreeBSD kernel provides a module which exports a Linux-compatible shim layer. However to make this work you must have all-Linux user-space: you must have Linux-built shared libraries, Linux-built binaries, etc. See https://www.freebsd.org/doc/handbook/linuxemu.html
It cannot work to have a binary compiled on FreeBSD use a shared library compiled on Linux. They have different C runtimes, different kernel system calls, etc. It won't work, just like using Linux shared libraries on Mac OSX, Solaris on Intel, or any other operating system won't work.
freebsd used to be able to run linux binaries, and included a set of linux .so's in the package. So it was possible at one point
I often see this file is included in many projects.
Is this mostly for Unix, Linux, MacOS applications?
and which c files would use this elf.h file?
elf.h is used for parsing and processing ELF files. You'll probably never see this on Windows because Windows does not use ELF files (it uses PE - Portable Executable - instead). OS X uses Mach-O, so elf.h isn't that common on OS X either (it doesn't ship as part of the default headers, for example). ELF format is primarily seen on Linux, where it is used for almost all binary executable files, from shared objects to executables.
I have a binary file in Linux, and I want to know what functions has it been compiled with.
My project consists on several object files, each one containing different functions. And sometimes I dont know which ones I compiled the executable with. How can I know?
I am compiling with a toolchain in different architectures (arm, mips...).
Thanks.
You can use the nm command on unix/Linux. or
You can use dumpbin on Windows.
If I just want to use the gsl_histogram.h library from Gnu Scientific Library (GSL), can I copy it from an existing machine (Mac OS Snow Leopard) that has GSL installed to a different machine (Linux CentOS 5.7) that doesn't have GSL installed, and just use an #include <gls_histogram.h> statement in my c program? Would this work?
Or, do I have to go through the full install of GSL on the Linux box, even though I only need this one library?
Just copying a header gsl_histogram.h is not enough. Header states merely the interface that is exposed by this library. You would need to copy also binaries like *.so and *.a files, but it's hard to tell which ones to copy. So I think the you'd better just install it on your machine. It's pretty easy, just use this tutorial to find and install GSL package.
So there are surely a lot of libraries out there. However the particular one is Gnuplot. Using it you even do not need to compile the code, however you do need to read a bit of documentation. But luckily there is already a question about how to draw a histogram with Gnuplot on Stackoverflow: Histogram using gnuplot? It worth noting that Gnuplot is actually very powerful tool, so invested time into reading its documentation will certainly pay off.
You cannot copy libraries from OS and expect them to work unchanged.
OS X uses the Mach-O object file format while modern Linux systems use the ELF object file format. The usual ld.so(8) linker/loader will not know how to load the Mach-O format object files for your executable to execute. So you would need the Apple-provided ld.so(8) -- or whatever they call their loader. (It's been a while.)
Furthermore, the object files from OS X will be linked against the Apple-supplied libc, and require the corresponding symbols from the Apple-supplied library. You would also need to provide the Apple-provided libc on the Linux system. This C library would try to make system calls using the OS X system call numbers and calling conventions. I guarantee the system call numbers have changed and almost certainly calling conventions are different.
While the Linux kernel's binfmt_misc generic object loader can be used to teach the kernel how to load different object file formats, and the kernel's personality(2) system call can be used to select between different calling conventions, system call numbers, and so on, the amount of work required to make this work is nothing short of immense: the WINE Project has been working on exactly this issue (but with the Windows format COFF and supporting libraries) since 1993.
It would be easier to run:
apt-get install libgs0-dev
or whatever the equivalent is on your distribution of choice. If your distribution does not make it easily available, it would still be easier to compile and install the library by hand rather than try to make the OS X version work.
I'm trying to use an API for a proprietary interface device on an embedded system (Freescale HCS08), and the provided files include headers (.h) and libraries (.lib). The header compiles fine with the rest of my code (standard C), but when trying to link against the library I get memory errors saying the file might be corrupted.
My understanding of libraries in C is somewhat limited as I work almost exclusively on embedded systems where magic things like stdio, files, and dlls don't exist; but would the (or any) library be platform specific? Does it contain fully (if there is any sort of level there) compiled code? Some of the other files provided are VS project files, so if it is the case that the .lib is platform-specific, it wouldn't be unexpected that linking a file meant for x86-Windows to an 8-bit compiler would fail; it could be just me.
Not only is a .lib file CPU specific (there would be no way to link HCS08 code to x86 code), it is toolchain specific (CodeWarrior won't talk to SDCC, GCC/binutils won't talk to Visual Studio).
Yes the .lib contains compiled code so it is platform-specific. If you have the source you should be able to re-compile it to your platform.