Writing Shared Libraries, first draft

[Mike Hearn]

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
   them.

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
   distros

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.

thanks -mike