amd64/127276: ldd invokes linux yes

[John Baldwin]

On Thursday 11 September 2008 12:40:04 pm Dominic Fandrey wrote:
> The following reply was made to PR amd64/127276; it has been noted by GNATS.
> 
> From: Dominic Fandrey <kamikaze at bsdforen.de>
> To: Rui Paulo <rpaulo at FreeBSD.org>
> Cc: John Baldwin <jhb at freebsd.org>, freebsd-gnats-submit at freebsd.org, 
>  freebsd-amd64 at freebsd.org
> Subject: Re: amd64/127276: ldd invokes linux yes
> Date: Thu, 11 Sep 2008 18:37:23 +0200
> 
>  Rui Paulo wrote:
>  > On Thu, Sep 11, 2008 at 07:01:09AM +0200, Dominic Fandrey wrote:
>  >> I don't need it to work, I just need it not to invoke linux binaries. 
I'm
>  >> using ldd in a script and by ldd not returning 0 the script should know 
that
>  >> it hasn't encountered a valid binary. Instead ldd opens a linux binary 
like
>  >> yes and the script spills out ys (yes) or waits for input from stdin
>  >> (md5sum). I'm pretty certain ldd is in no way meant to invoke programs.
>  > 
>  > I chatted briefly with John about this. The way our ldd works is by
>  > setting the environment variable TRACE_LOADED_OBJECTS and after some
>  > dlopen() magic it exec()'s the binary. FreeBSD rtld detects the 
environmental
>  > variable, prints the list of shared objects and quits.
>  > 
>  > Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will
>  > just run the Linux binary (Linux rtld will ignore the rest).
>  > 
>  > Also, ldd wil return 1 on static binaries. Your best bet is to use
>  > file(1) to detect FreeBSD binaries. Something like `file $binary | grep
>  > FreeBSD-style` does the trick.
>  > 
>  > Regards,
>  
>  Ok, thanks. I have already created a workaround with readelf, but I'd still
>  consider this a bug in ldd. Shouldn't it check the elf brand if it only
>  works for a single one?

FreeBSD binaries from various releases have been branded in different ways.  I 
would consider it more of a user error to run ldd on a Linux binary. :)  You 
could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains 
how it works and why it will execute any binary using a different runtime 
linker.

-- 
John Baldwin