Re: The LinuxProblems page on the Autopackage wiki

On 8/28/07, Michael T <[email protected]> wrote:
>
>  Hello,
>
> I read the LinuxProblems page on the Autopackage wiki
> (http://trac.autopackage.org/wiki/LinuxProblems), and found
> it to be very interesting.  However, I do wonder whether some of the
> problems are not the result of a certain misunderstanding.  It seems to me
> that the "central" build environment which comes with most Linux
> distributions (i.e. /usr/include, /usr/lib, etc) is one specifically aimed
> at producing binaries for that particular distribution.  In fact, that
> central build environment is usually what the user needs (if they are
> building software at all).
>
> However, if you are building for another installation environment, it seems
> to me that the right thing to do is to install the headers and libraries for
> that environment locally (or rather, ones which have APIs/ABIs supported on
> all target systems) and build with -nostdinc and -nostdlibs, or equivalent,
> but using the local directories instead.  That should actually solve many of
> the problems which you point out on the wiki page.
>
> Obviously, it would be even nicer if the centrally installed libraries and
> headers supported building against older APIs and ABIs (i.e. with the right
> #defines or whatever), but there is always a conflict between new features
> and backwards compatibility there, and I suspect that that is not a feature
> which is in great demand in a mainly source-based ecosystem like Linux.

There are multiple issues here:

* The mapping between code, API and ABI should be that code has a
single API and compiles into a single ABI. When this rule is broken,
all hell breaks loose: depending on ./configure switches to python,
you have a 2 byte wide unicode API/ABI or a 4 byte wide one, and they
are incompatible with each other. Sadly, even the most used library on
Linux, libc, generates entire families of ABIs which are not
compatible with each other, depending on whether you have thread-local
locales for example. The workaround used in autopackage, which is to
compile with special headers, happens to work for the libc case
luckily, but it doesn't for monty python's flying circus :).

* You can always set up a special build environment in a chroot jail
or a virtual machine, that will generate binaries that are
semi-compatible across distributions. Is there any documentation on
how to set up such an environment? No. Is there any Linux distribution
out there whose purpose is to compile software so it works on all
other distributions? No. If both these things existed would more
people do it? Probably not, it's still a major hassle. Autopackage's
apbuild doesn't require you to install a new distribution, it does a
good job with the existing tools.

* The current practice is lockstep libraries, so at each point in time
(eg. 6 months) you take the latest version of every library out there
and compile them against each other to create a distribution. That's a
terrible thing to do, because backporting a package to an older
version of the distribution either means compiling it again against
the older libraries, or dragging dozens of new libraries into the
older version of the distribution when the user wants to install the
tiniest backported package. I honestly don't understand why no
distribution has pushed for binary compatibility to save themselves
from all this pain.

> Regards,
>
> Michael

Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]