This is the mail archive of the
mailing list for the GCC project.
Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- From: Marcin Dalecki <martin at dalecki dot de>
- To: Marcus Meissner <meissner at suse dot de>
- Cc: Edward Peschko <esp5 at pge dot com>, Dan Kegel <dank at kegel dot com>,gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- Date: Wed, 26 Jan 2005 17:02:29 +0100
- Subject: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- References: <41F5E862.email@example.com> <20050125195606.GA29787@venus> <20050126071355.GB21489@suse.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
with what the vendors out there are using and distributing. It isn't
even remotely compatible. (NPTL anyone for example?) Please don't
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
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
situation, It is looking for runtime properties of the host system. It
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
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
mistakes, since it is looking at the system headers. Fortunately this
supposed to be obsolete, so those mistakes don't hurt. Building on 2.6
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
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
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
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
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
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
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
specification (in the sense as first defined by Alfred Tarski),
with proper full coverage of functionality and so on. Formal
LSB "compliance" is just a marketing joke for good feelings. Not much
It shouldn't call itself a standard if taking the meaning of standard
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
Just create your own Linux distribution.
The entropy of kernel variants and libraries is in fact quite
preventing the existence of a true vendor software market for Linux. I
expect the situation to change. Vendors will simply stick to a single
qualified to run their software for the foreseeable future. Small
vendors will be
locked out because they can't afford to maintain releases for
variants of systems out there. There will thus be only server
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
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
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
with gcc-3.4.3 (glibc or uClibc or newlib) and recent binutils running
rebuildable from *scratch* without attention... No it isn't crosstool
And I'm not far away from making the cross environment fully functional
MacOSX and Win32. Actually the only not working part here is indeed the
shame aka glibc.