Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking

[Marcin Dalecki <martin at dalecki dot de>]

On 2005-01-26, at 08:13, Marcus Meissner wrote:
> > Well, that might be the case with your fifty patches, but it sure
> > isn't the case with mine..
>
> We try to be binary compatible with upstream glibc.

Just a question: What is the upstream glibc? I suppose you are talking
about the tarball found on ftp://ftp.fsf.org? Well that has not much in 
common
with what the vendors out there are using and distributing. It isn't
even remotely compatible. (NPTL anyone for example?) Please don't 
misguide
people to try using it on even remotely recent kernels or with remotely
GCC versions. It isn't going to work! Don't guide the people to waist 
their
time!

> Very likely you did something wrong, building glibc is not for
> the faint at heart.

No. The glibc setup system is deeply broken by leak of clue and 
concept. I stand
by those words. Those are not flames but just the adequate description 
of the
situation, It is looking for runtime properties of the host system. It 
greps/seds/awka
like an insane monkey through the installed system header hierarchy to 
decide what to
enable or not. Thus there is no sane way to just control in imperative 
way what it should
choose and what not. Usually the mistakes it does just slip silently 
through
your hands. But building glibc in a TRUE cross build environment, like 
building glibc on
MacOSX for Linux, will immediately reveal how contorted this all is.

A nice example how this will bite you even if working on Linux is the 
wait() system call.
It's implemented on some CPU targets by the kernel on some others there 
is just a
stub saying that it's invalid and on even different ones it is not 
there at all.
Depending on where you build and what you target, glibc setup will make 
different
mistakes, since it is looking at the system headers. Fortunately this 
syscall is
supposed to be obsolete, so those mistakes don't hurt. Building on 2.6 
kernel
system and on 2.4 kernel system will give you utterly different 
results. Why doesn't
this break even more frequently? Well simply:

1. Distros are bootstrapped on themself step by step apparently.
2. Nobody is using the new system calls, and Linus is careful to never 
remove old
   ones.
3. Well, point 2 isn't true. But nobody cares about Oracle breaking 
apart if moved to
   another distro or after upgrading ;-).

You think I sound too harsh? Then please be aware that a glibc build 
will spend
most of it's time in Makefile dependency generation onanism. Yes it 
takes it much
longer to decide what to do then actually doing it. Drepper found a way 
to make make
run slower then gcc, which as we all know is applying far more 
sophistication to
it's input then the make command. Or just try to use a true sed or awk 
instead of the ones
coming with glibc... It's a sad sad world...

At some point in time I have discovered a place where it was even doing 
"runtime setup", thus behaving different whatever it found a particular 
idiotic
useless broken interface file in /proc or not (stat("/proc/blah").
I discovered this by crafting an embedded system with a kernel which 
didn't contain this
particular crap in /proc. And suddenly threading did fall apart because 
glibc was thinking
it was running on a different kernel then it actually did. Nice and 
cute isn't it?
Never mind such "tricks" are scattered through the whole source code of 
glibc...

Nothing of the above is even remotely documented... Not that I would 
expect it after
looking in to the innards of this ugly beast.

<SARCASM>
Yes it is that BAD! It's like the 3rd LIBC for the next 1000 years...
Great promises, awful start, but then came Stalingrad and the rest we 
all know.
</SARCASM>

> The SUSE included glibcs are LSB compliant, so there is no need to
> migrate away from them.

And what does give LSB? LSB isn't even a near shoot from being a proper 
formal
specification (in the sense as first defined by Alfred Tarski),
with proper full coverage of functionality and so on. Formal 
verification anybody?
LSB "compliance" is just a marketing joke for good feelings. Not much 
more.
It shouldn't call itself a standard if taking the meaning of standard 
by word.

> > But there doesn't seem to be a good way to do this.  The best solution
> > someone has come up with so far is run stuff chrooted, which isn't
> > really a solution at all, because it doesn't allow for 
> > interoperability.
>
> Just create your own Linux distribution.

The entropy of kernel variants and libraries is in fact quite 
effectively
preventing the existence of a true vendor software market for Linux. I 
just don't
expect the situation to change. Vendors will simply stick to a single 
distro as
qualified to run their software for the foreseeable future. Small 
vendors will be
locked out because they can't afford to maintain releases for 
bazillions of
variants of systems out there. There will thus be only server 
applications or
trivial statically linked console apps for linux out there.

However embedded systems will be fine.
But you need a lot of expertise and suffering through Dreppers bad 
habits
to really make such a thing going... I really miss the times of the
very fine HJ Lu libc5 work. He did an awesome job! Yes it wasn't 
perfect.
But it wasn't artificially contorted. Hey at least we have
quite well working binutils nowadays. But Drepper? Give ma an
aspirin please. I remember the pain I suffered from it just too well...

PS. I have a full system cross build for divers intel/PowerPC/MIPS/ARM 
platforms
with gcc-3.4.3 (glibc or uClibc or newlib) and recent binutils running 
for myself
rebuildable from *scratch* without attention... No it isn't crosstool 
based.
And I'm not far away from making the cross environment fully functional 
on
MacOSX and Win32. Actually the only not working part here is indeed the 
libc of
shame aka glibc.