From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4181 invoked by alias); 26 Jan 2005 16:02:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4024 invoked from network); 26 Jan 2005 16:02:38 -0000 Received: from unknown (HELO ds01.webmacher.de) (213.239.192.226) by sourceware.org with SMTP; 26 Jan 2005 16:02:38 -0000 Received: from [192.168.0.51] (dialin-145-254-149-113.arcor-ip.net [145.254.149.113]) by ds01.webmacher.de (Postfix) with ESMTP id 878274441E8; Wed, 26 Jan 2005 18:03:33 +0100 (CET) In-Reply-To: <20050126071355.GB21489@suse.de> References: <41F5E862.2030906@kegel.com> <20050125195606.GA29787@venus> <20050126071355.GB21489@suse.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Edward Peschko , Dan Kegel , gcc@gcc.gnu.org, libc-alpha@sources.redhat.com From: Marcin Dalecki Subject: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking Date: Wed, 26 Jan 2005 16:30:00 -0000 To: Marcus Meissner X-SW-Source: 2005-01/txt/msg01540.txt.bz2 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. 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.