This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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

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.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]