Monday 27 December 2010

elfrewrite - why did i bother?

Someone kindly suggested that the effort in building elfrewrite
was wasted and that there are many well-known existing methods to
achieve the result of a universal binary.

I acknowledge there are many ways to do this, but none of them
fulfil my need or desire.

In days of old, one would pick an old release of a platform and
stick with it. I stuck with HPUX-10 for more than a decade, AIX3.2
for more than a decade, and for Solaris, 2.6 was a good platform.

But Linux is different. Each new release of kernel or glibc was
like a "bomb" - you open it carefully, and see what surprise are in store.
glibc introduces many versioning dependencies as key libc functions
are enhanced in a way that is not backwards compatible.

A suggestion - and one I use religiously, is Virtual machines - have
your build environment in a VM. I do this, but I dont like building
in a VM something different from the main platform I use daily. I
currently use Ubuntu 10.10 and will upgrade to 11.04 when that comes
out. I have issues with Ubuntu, but it suffices and most of my hardware
works (apart from software suspend).

elfrewrite has no dependencies (other than itself and a libelf
library written from scratch, as part of the CRiSP build environment).

What elfrewrite allows me to do, is, whenever an app fails to run on
another OS platform (AS4, AS5, archlinux, etc), I can run it on the
target binary and be done. No rebuild from source; no need to
determine which version of gcc/ld had -Wl,hash-style= implemented,
and a possibility to enhance the mechanism to allow performance or
"working" or both.

Why do I even bother to write and publicise this?

Because I can. Because it interests me. Because when I first hit
the problems leading to its necessity, determining the root cause was
impossible even with google. Now I know what to search for and understand
the rationale behind these changes, and there are many good articles
on the web on the innards of ELF. But there are far more "why doesnt X run on
my system?" along with various non-useful suggestions (involving
upgrading parts of a system you may have no control over, to
rebuilding an app). I gave up building FSF apps a long time ago,
when faced with the complexity of lib dependency and broken
autoconfig make systems.

We all write code to build something better, and we dont have
time to decipher every rationale and change in a foreign piece
of code - most open source apps have become too complicated (and
I dont mean that in a negative sense, but simply trying to make
enhancements or fixes is difficult because of the size of the apps).



Post created by CRiSP v10.0.2c-b5920


No comments:

Post a Comment