Writing Shared Libraries, first draft
mike at navi.cx
Sun Nov 7 01:06:31 EET 2004
On Sat, 06 Nov 2004 14:34:18 -0500, Havoc Pennington wrote:
> I think you just give people a very simple rule: build your binaries on
> the oldest version of the OS you want to support.
That has a bunch of awkward problems:
1) It's not something you can expect hobbyist open source developers to
do. Nobody especially wants to maintain a dual boot/VM system just for
building binaries, especially when there's actually no need.
2) You end up with dependencies on old libraries that aren't necessarily
installed on the users machine. For Crossover this is a problem with
ncurses at least, as well as a few other random libs I forget. You
build on the old distro, now your dependencies are obsolete. Oh sure,
in theory there are compat-foo packages, in practice nobody ever has
3) Its tempting to statically link to get around that problem, but then
you run into problems with accidentally linking in buggy/insecure libs.
So you have to either have totally separate sets of modern libraries
which rather defeats the point, or have a half-old, half-new distro.
You can also provide dlopen codepaths for both versions. This sucks *hard*.
4) Got to keep that box well defended. No security updates for old
5) Got to maintain compatibility with ancient [buggy] toolchains
6) It's not competitive with Windows. Do you have to compile on Windows 95
to ensure all your users can run your simple utility? No, of course not.
You just make sure you don't use any NT only features and away you go.
The system works with you to help you do this.
Having to have a magic build environment based on some obsolete, buggy,
insecure Red Hat 6.2 variant (actually we upgraded recently, the old
setup was too much of a pain) is something the majority of the worlds
software developers see as alien and bizarre. Building binaries that
work on older OS editions is hardly difficult, so it's taken for granted
that this just works. On Linux it doesn't, and it's a huge time sink.
It's not hard to allow this, for libraries it basically means using header
versioning and not using messed-up glibc style symbol overloading.
There are a few other issues you run into in practice, like pointless
micro-optimizations modern GNU toolchains use which silently
make you depend on eg, a gcc3/glibc2.3 based system. Fortunately they
can be disabled if you know the right flags. If you don't know the right
flags, that's what apbuild (from autopackage) is for. It's "policy in a
box" we update as time goes by to allow you to build for older distros.
More information about the xdg