From owner-freebsd-current Tue Feb 11 16:01:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA00417 for current-outgoing; Tue, 11 Feb 1997 16:01:13 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA00410 for ; Tue, 11 Feb 1997 16:01:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA29345; Tue, 11 Feb 1997 16:54:51 -0700 From: Terry Lambert Message-Id: <199702112354.QAA29345@phaeton.artisoft.com> Subject: Re: linux ELF codine no go on 2.2 Gamma To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 11 Feb 1997 16:54:51 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, swallace@ece.uci.edu, current@freebsd.org In-Reply-To: <199702112305.JAA07951@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 12, 97 09:35:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > ... and you are ignoring me again. Branding them when you get them is a > REAL PAIN IN THE ASS, and there is no guarantee that they'll be any > better next time. (Do you actually have to deal with commercial outfits > doing code for Linux? I wot not.) You're right, I don't. That's because there are comparatively few of them, despite what Linux advocates would have you think. Besides which, you are ignoring the fact that the tools Linux uses will automatically brand any newly created binaries. > As for "updated tools", you read the glibc 2.0 announcement posted here > a while back, no? You read the part where they're moving _closer_ to > the SVr4 ABI and using the same linker path, ie. making it > _harder_ to tell the two apart? The linker path is not the correct way to tell them apart. That was a seriously bogus differentiator. If they move fully to the SVR4 ABI, then there's no *need* to tell them apart. > > Assuming your path "magically" includes compat/* as a prefix for each > > and every path component. Not otherwise, however. > > Na und? "Install all your Linux stuff in /compat/linux" is a much > easier instruction to follow than "Find all the ELF binaries in every > Linux package you install and execute this command on each of them". How do I edit my path? Part of it I inherit from system files, and part of it from my own resource files (.cshrc/.login). Will you hack the system path files when you install an ABI compatability package? Will you hack the default user resource files that are used as templates by the adduser? What about the users already on the system? This is an untenable soloution. The people installing will already have to hack the install to get the code onto the system anyway (RedHat pacakage management for FreeBSD, anyone?). > > What other ELF binaries, not fixed in the next release, are unbranded > > non-SVR4-EABI ELF binaries? > > All of the current Linux ones, many of which will be in use for not > inconsiderable periods of time, and a good many of the upcoming Linux > ones which will be produced by commercial software houses that _aren't_ > going to be following the bleeding edge of Linux 'development'. > > Look: dump the hair shirt and accept that in the short term this is a > prudent step that will help to reduce by some degree the stress of > dealing with people that are trying to do "real" work with the system. I will, if you will hack the default paths to add the wart to recognize the wart you are suggesting; otherwise, you're only doing half the necessary hack. A better soloution is to create a "package" for commercial Linux product distributions, since you have to do a damn hand-install anyway to get them installed, and then have them do the brand. You solve the binary recognition and the hand-install problems at the same time, and you do it without hacks. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.