Date: Tue, 15 Oct 1996 22:41:18 +0200 (MET DST) From: sos@FreeBSD.org To: terry@lambert.org (Terry Lambert) Cc: sos@FreeBSD.org, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.org Subject: Re: Linux compat issue(s) Message-ID: <199610152041.WAA02300@SandBox.CyberCity.dk> In-Reply-To: <199610151906.MAA01321@phaeton.artisoft.com> from "Terry Lambert" at Oct 15, 96 12:06:01 pm
index | next in thread | previous in thread | raw e-mail
In reply to Terry Lambert who wrote:
>
> > > Should I assume that this is the "what static ELF binary is this" problem?
> >
> > Exactly, the static ELF program is run as a FreeBSD native bin, there
> > is no way to know better (yet).
> > I guess we'll have to provide a solution for this shortcoming in
> > ELF (WHO said ELF was "the way to go" *sigh*)
> > I can do a "quick&dirty"(tm) little program that marks ELF bins so that
> > we can distinguish them, but it breaks the ELF std. one way or another.
>
> With respect, Linux distinguished the SVR4 vs. Linux ELF binaries.
>
> It does this by looking for the ld.so reference (which it always
> includes so it can use dlopen/etc.) and seeing the word "linux" in
> the ld.so file name reference. I think they also look at the crt0
> startup code in the static binary case.
How come that took so long Terry ??
So do we in the dynamically linked case, almost all ELF implemetations
on the x86 platform use different named/located interpreters.
It is only the statically linked binaries that is the problem.
Linux has the same problems we do, they have implemented another
hack than the one I suggest, just their method isn't very robust
but they're used to that, right :)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sxren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610152041.WAA02300>