From owner-freebsd-current Tue Feb 11 12:11:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA15318 for current-outgoing; Tue, 11 Feb 1997 12:11:01 -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 MAA15311 for ; Tue, 11 Feb 1997 12:10:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA28867; Tue, 11 Feb 1997 13:04:06 -0700 From: Terry Lambert Message-Id: <199702112004.NAA28867@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 13:04:05 -0700 (MST) Cc: swallace@ece.uci.edu, msmith@atrad.adelaide.edu.au, current@freebsd.org In-Reply-To: <199702110616.QAA01350@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 11, 97 04:46:09 pm 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 > > Probably what would be reasonable to do is if all else fails and > > the elf type is not known, use the /compat/(*) as a hint for the type. > > That was, indeed, all that I was planning to do. With -current in such > a fluster at the moment, I think I'll keep my mitts off for a while > though. All ELF binaries should be branded, instead. The patches for defacto branding of all ELF binaries generated by GNU tools have already been submitted. What we are arguing about here is non-branded binaries produced by non-GNU tools (default: treat as SVR4 EABI binaries) and non-branded binaries produced by prepatched GNU tools (default: treat as an error to not have run "brandelf" on them). The "loaded from" hints cruft is really, really unnecessary. If you have a problem, get the people causing it to use fixed tools. Wasn't one of the reasons FreeBSD cited for not moving to ELF the idea that the tools had not settled? If you are willing to patch unsettled tools in software this way, you have removed the reason for not moving to ELF... and you should move to ELF first, before hacking in cruft to support your "premature" move to ELF (quoted, since all FreeBSD ELF binaries, of which there are none, could be created with the patched tools, *only*, and never have the problem you are trying to glue). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.