Linked by Thom Holwerda on Wed 9th Nov 2011 21:26 UTC, submitted by edwin
General Unix Way back in 2002, MIT decided it needed to start teaching a course in operating system engineering. As part of this course, students would write an exokernel on x86, using Sixth Edition Unix (V6) and John Lions' commentary as course material. This, however, posed problems.
Permalink for comment 496957
To read all comments associated with this story, please click here.
RE[3]: binary for windows....
by Vanders on Fri 11th Nov 2011 12:48 UTC in reply to "RE[2]: binary for windows.... "
Member since:

Shared libraries are the cause of all dependency problems

Library versioning and symbol versioning are a solved problem. It's only when developers do not follow the standards that they introduce problems. In a properly managed library dependency issues are non-existent. Glibc is the obvious example here: since Glibc2 ( was introduced on Linux, the library has remained both forwards and backwards compatible.

Consider, that shared libraries can't be optimized over API calls. It might take 30 bytes to call a libc function, which shifts the bytes around again to do a syscall. In a static application, it could theoretically optimize away all the glue code to do a syscall directly while saving space.

The glue code is either needed, or it is not needed. If it's needed, then you can't simply "optimize it away". If it's not needed, then you can just remove it from the syscall shim.

Remember that in many cases the syscall shim will also attempt to avoid a syscall. It's much, much better to do the sanity checking and return early if the arguments are bad before making the syscall. It may require a few more instructions before the syscall happens, but that's still far less expensive than making the syscall only for it to return immediately because the arguments are wrong.

In some cases it's also entirely possible for the syscall shim to satisfy the caller entirely from user space I.e. it doesn't even need to call into the kernel.

Obviously we have to look at bigger libraries too, like libjpg, but even there I wonder how much space would be wasted if it were statically compiled.

This isn't to preclude to the use of shared libraries for applications which are genuinely related and deployed together. But I do see an awful lot of application specific libraries under /lib which have to be managed in lockstep with their associated application, why should these be shared libraries at all?

Now this is where I do a 180 and agree with you! Shared libraries are overused and in a large percentage of cases are used inappropriately. As a simple rule of thumb I'd prefer that system libraries are shared, and any third party libraries required by an application should be static. That's not fool proof, but it's a starting point.

Reply Parent Score: 3