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
Related
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.
I've a project completely coded in C with dependencies on gnuplot, gtk, GNU Scientific Library, etc. It works fine on my machine.
However, how can I package it as a standalone executable which would be platform and OS independent?
Even if it works for any Linux platform, it's fine.
However, how can I package it as a standalone executable which would be platfrom and OS independent?
You can't. At least the standard C library has to use OS-specific APIs (syscalls, library functions) at many places.
Even if it works for any Linux platform, it's fine.
Linux is kind of a moving target, still this is often possible by linking all the libraries statically -- see your compiler's documentation for how to do that.
You can't have something a C program run on different OSes without recompiling.
This being said, if you want to compile your your program for a single platform like Linux, static compilation may usually be a solution, but it's not a use case handled by GTK+, so you might be able to build the other dependencies statically, but GTK+ and its dependencies will need to be built dynamically and shipped separately.
Usually you'd then be advised to package your application for your GNU/Linux distro of choice using RPM/DEB packages, but that would work for only that one distro.
So the best choice I see is to use flatpak to bundle your dependencies, and have flatpak installed where you want to install your app.
I am learning network programming through the sample source codes from this link http://cs.baylor.edu/~donahoo/practical/CSockets/textcode.html. During the compilation, just wondering why in Solaris environment, i have to manually link socket and nsl library in the make file but when in the linux machine, i dont need to do that ?
Documentation used: http://developers.sun.com/solaris/articles/solaris_linux_app.html
This is because linux's libc, the glibc (-lc, which is linked by default to all programs) includes socket part of POSIX; and nis/nis+ dynamic libraries in linux are loaded dynamically by libc too.
But in Solaris, there are a lot of libraries with basic functionality, which are not in libc.
(libc, libucb, libmalloc, libsocket, libxnet, etc). I think, it was a design solution to allow user link only parts of API he needs.
In linux there are some basic libraries outside libc too: libaio, librt, libm.
With separate library it is easier to update only some parts of system; and it is possible to have several implementations (e.g. to provide greater compatibility/workarounds with older versions of UNIX) of some libraries coexisting in same system.
This question is discussed a lot, e.g. http://web.archiveorange.com/archive/v/KcxCHdLNpD6NANxmAt3b http://mail.opensolaris.org/pipermail/opensolaris-code/2007-January/010316.html
are seriously considering folding libnsl and libsocket into libc.
It would be nice to move ONLY the current POSIX-based and other
standards-based functionality (Unix98 etc.) libnsl+libsocket functions
to libc and keep all the compatibilty-wrapper stuff in libnsl/libsocket
to avoid that libc gets bloated with 20years of Unix
backwards-compatibility workarounds
Because in Linux, the entire networking API is implemented in libc.so which is linked into every C program by default, while in Solaris, its implemented in separate libraries.
Is it possible to have glibc and uClibc based applications running side-by-side on one system?
Background: We have binary gcc based cross-compiler configured to link with uClibc. We have cross-compiled glibc with it. Now we want to build some applications so they will link with the glibc rather than uClibc. We don't want to rebuild the compiler.
There's no problem with glibc and uClibc living side-by-side with some programs linking to one and other programs linking to the other. However, there is a problem with additional libraries. Each shared library on your system will be built against either glibc or uClibc (using the corresponding headers, which define distinct ABIs for the standard library functions), so for example if both a glibc program and a uClibc program need ncurses, you'll need to have two versions of ncurses built, and have a way of ensuring that the correct one for the given program gets loaded at runtime. Alternatively, you could choose to only use one set of shared libraries, and use static libraries for programs linked to the other libc, but you'd still need to build your 2 sets of libraries.
Yes, it should be perfectly possible, but you might have to play around with LD_PRELOAD_PATH. If you are linking statically, change to dynamic linking.
It is nearly impossible to mix them in the same FHS, as the ABI and include dir are incompatible. However, you could install either of them in an directory offset, by tweaking dynamic-linker field in ELF and exploiting sysroot feature in gcc/binutils. An on going experiment is in Gentoo community[1], known as Prefix/libc.
http://wiki.gentoo.org/wiki/Prefix/libc
I have a linux shared library (.so) compiled with a specific version of libc (GLIBC2.4) and I need to use it on a system with different version of libc. I do not have sources for the library in question so I cannot recompile for the new system. Is it somehow possible to change the dependencies in that library to a different libc?
If you need the .so on a system with an older glibc, you would need the source code and recompile/relink it with the older glibc. The alternative is to install the required glibc on the old system in a non-default location and adjust the LD_LIBRARY_PATH for the executable that needs this .so
If there's a newer glibc rather, it should normally not be a problem as glibc tend to be backwards compatible.
Unless your library really uses interfaces that changed (unlikely), you can just hexedit the references to versions in the resulting .so file. They're all text anyway.
Best you can do is compile the old glibc version for your system and then build your application with that glibc and your shared library. Ugly though ...