floyd

[Log in to get rid of this advertisement]

This maybe a bit of a newbie question, but I was wondering, if BSD and Linux are both (pretty much) POSIX compliant, what stops programs written on one compiling for the other? Why does BSD need a linux "compatibility layer"?

Also, is it possible for a program *compiled* on Linux to run on BSD? Or do you need to re-compile? Again, if so, why, given POSIX compliance... (I read something once about differing binary formats? Whats the deal there?)

I know back in the day SYSV and BSD etc tried to differentiate eachother for reasons of competition, but today in the open-source world I think this is largely irrelivant. What would have to be changed for all the unices to run eachothers programs?

Thanks

Floyd

llama_meme

Yes both are POSIX compliant, and generally you can compile Linux applications on FreeBSD without any problems.

The Linux compatibility layer alows binaries compiled on Linux to run on FreeBSD. You need a compatibility layer to do this for a number of reasons (e.g. that FreeBSD and Linux use different libc libraries, possibly have different register useage conventions, etc.) FreeBSD and Linux both use the same binary format (ELF).

Incompatibilities between Linux and FreeBSD aren't deliberate; they're just a result of differing histories and development goals.

Alex

parle

The most marked differences I´ve seen between the two OSes is in the compiling of source into binaries. The kernels of Linux and BSD may be aiming for the same compliance (POSIX), but take different approaches to do so. BSD tends to be more security-aware, and many of the core libraries, and system files are quite different because of those approaches and different priorities in the development cycle. Most linux binaries under BSD´s binary emulation run as fast or faster (or so it seems) than running natively in Linux. In short, check your ports tree first if you want something to add; if it isn´t there, then go for source and compile, or use a Linux binary. That is the path of least headaches.

floyd

Thanks for the info guys. I am now clearer, but still have a couple more questions for the sake of expanding my knowledge

Is it the c library (eg. glibc for linux) that implements the posix system calls, which then interface with the kernel on its native level?

Second, when you write code that uses system calls, does it statically link or dynamically link to the c library?

If it linked dynamically, and you wrote code to a strict POSIX specification, would it be possible to run it on both Linux and BSD without a compatibility layer? I say this, because if it is dynamically linked, then all that should really matter is the interface and not the implementation right?

Sorry if these questions are a bit basic, just want to understand how things work

Thanks

Floyd

llama_meme

Yes.

I think it's dynamic on both Linux and FreeBSD.

Not necessarily - it's quite difficult to make a clean separation between interface and implementation in C (e.g. macros which manipulate an abstract data structure would put implementation details of an operating system's libc in your code after preprocessing).

Alex

floyd

Ahh, gotcha

Thanks for clearing that up. Is there a goal to maybe make them compatible in the long term? ie. Take those macros and things out? I have always been told macros are evil and not to use them, however I have not really done any system programming.

Compatibility is not such a big deal at the moment, because most Linux/BSD users are fairly proficient and re-compiling isn't a big deal, plus the compatibility layer helps. However, in the future, if the Unices want to stand strong as a desktop competitor, I think strength will come with combined numbers with complete compatibility, so developers only really have to write and test things once and consumers simply wont have to worry.

Things like the Linux Standards Base are a step in the right direction, that way all directories and stuff will hopefully be in the expected place. I know that this doesnt apply to BSD, but maybe in the future it will become the Unix (if they are allowed to use that word) Standards Base? freedesktop.org is also a big step in the right direction in my mind. I like the fact that there is competition between distrobutions and unix flavours, it breeds innovation. However I dream of a time that people can pick any unix-flavoured kernel, pick any desktop, and things will just run

php

You have to realize that the two are licensed differently. This license changes the way things are done for both of them.

floyd

I dont see why it should, while the licensing changes the method of development/distrobution/use, it should not effect the function/interaction of any particular piece of software. This is the whole point of having standards in the first place. This is exactly how Linux came about in the first place, and consequently gained so much popularity: it is essentially a unix clone. However it would seem small and inevitabely unnecessary differences stop it from being 100% compatible on any particular platform.

Obviously companies like Apple can make a version of BSD that might be incompatible in certain areas and hide the source, but with the mainstream BSDs I dont really see any motivation for this.

llama_meme

Well the only way to make the two compatible would be for FreeBSD to use glibc, or for Linux to use BSD's libc. The development effort required to do this would be quite substantial, and switching an OS over to a new libc implementation can cause a lot of anguish (just look a few years back in Linux history). It's just not worth all the trouble, since no-one expects binaries to be useable on more than one OS anyway -- the POSIX standards certainly don't have this goal in mind; they're more concerned with C source portability.

Alex

chort

Really the whole argument is pretty much moot, because if they did natively use the same libraries, etc then either Linux would be another BSD, or BSD would be a Linux distro. Obviously there are many reasons why they're being developed separately, not the leaset of which is licensing (BSD is truly free, while Linux is only "open").

The Linux binary compatibility is in the kernel any way, so I don't see what the big deal is.

parle

I read somewhere that FreeBSD is changing some of the way it does business, in that some parts which have been traditionally statically linked (/bin and /sbin in particular) are soon to be dynamically linked. As far as I know that may also be the case with libc.

libc and glibc have to do with the C language, of which the largest part of *nixes are built.

Also, remember that Linux and BSD have different approaches to building their kernels. Linux has most "gut level" items like basic filesystem, disk, and memory management in the core, leaving external modules to handle such items as SCSI and NIC support, while BSD "internalizes" these items. In fact, sound support is best set up in the kernel of BSD. The upside is that an optimized BSD kernel can run very fast and lean, but the downside is that adding some new hardware may require rebuilding the kernel. (still a fairly easy process if you follow the handbook)

Most Linux application sources will compile without a hitch under FreeBSD, but there are some that won't without the FreeBSD patches added in ports (Mozilla 1.5 comes to mind)

llama_meme

This is confusing the issue a little. Libc itself has been a (potentially) dynamic library for ages on Linux and FreeBSD. However, in FreeBSD, binaries in /bin and /sbin have been (as a special case) statically linked to libc, so that they can still be used in the event of a major system screwup. The change in FreeBSD-current is to change these binaries to be dynamically linked to libc -- libc itself hasn't changed at all.

FreeBSD also has modules. Sound support is done in the kernel on both Linux and Freebsd, and can optionally be compiled as a module in both. NetBSD and OpenBSD, however, don't have modules (or at least didn't until recently; I haven't been keeping track).

Alex

floyd

Hmm, maybe I'm missing something fundamental here about the way binaries are linked. I know that in implementation, the 2 c libraries are completely different, however if their interfaces are the same, why should it matter? If the libraries are source compatible, meaning that you can interchange between them with a simple re-compile, then shouldn't they be binary compatible when dynamically linking them on the same architecture? Isn't that part of the point of dynamically linking to libraries? Besides saving memory when multiple programs want to use the same library, there is also the advantage (or disadantage if new bugs are introduced and break things) of being able to update the library without changing the progam? Does this not imply that when dynamically linking the library, as long as the function interfaces are the same, that the implementations of those functions can be altered, with no effect on the program itself? And in effect, arent the 2 c libraries using the same function interfaces, but with different function implementations?

Judging by the previous replies, there is a flaw in that logic, I would just like to know what it is Again, Im sorry if I am suggesting something fundamentally ignorant here, I am just trying to expand my understanding

llama_meme

In general, source compatibility != binary compatibility (at least it doesn't in C). The examples of macros I gave before illustrates this. For concreteness, look at how the errno variable changed in various UNIXs. Originally, it was just a normal gobal variable, but when multithreading was added, it became a macro which gave an expression for the errno for the current thread of execution. The use of a macro kept the interface to libc source-compatible with older versions, but binary compatibility was broken. Another example is differeces in register useage conventions between different OSs running on the same architecture, although I don't think this actually applies in the case of FreeBSD/Linux.

Alex