Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Feb 1997 16:54:51 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        msmith@atrad.adelaide.edu.au (Michael Smith)
Cc:        terry@lambert.org, msmith@atrad.adelaide.edu.au, swallace@ece.uci.edu, current@freebsd.org
Subject:   Re: linux ELF codine no go on 2.2 Gamma
Message-ID:  <199702112354.QAA29345@phaeton.artisoft.com>
In-Reply-To: <199702112305.JAA07951@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 12, 97 09:35:02 am

next in thread | previous in thread | raw e-mail | index | archive | help
> ... 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702112354.QAA29345>