From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 11 17:57:03 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0F89106574A; Thu, 11 Sep 2008 17:57:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 86BAD8FC1F; Thu, 11 Sep 2008 17:57:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8BHuVYP035323; Thu, 11 Sep 2008 13:56:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Dominic Fandrey Date: Thu, 11 Sep 2008 10:38:32 -0400 User-Agent: KMail/1.9.7 References: <200809101744.m8AHiaQq053643@www.freebsd.org> <200809101610.13951.jhb@freebsd.org> <48C8A615.7070800@bsdforen.de> In-Reply-To: <48C8A615.7070800@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809111038.32311.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 11 Sep 2008 13:56:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8219/Thu Sep 11 11:02:39 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/127276: ldd invokes linux yes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 17:57:03 -0000 On Thursday 11 September 2008 01:01:09 am Dominic Fandrey wrote: > John Baldwin wrote: > > On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: > >>> Number: 127276 > >>> Category: amd64 > >>> Synopsis: ldd invokes linux yes > >>> Confidential: no > >>> Severity: serious > >>> Priority: medium > >>> Responsible: freebsd-amd64 > >>> State: open > >>> Quarter: > >>> Keywords: > >>> Date-Required: > >>> Class: sw-bug > >>> Submitter-Id: current-users > >>> Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 > >>> Closed-Date: > >>> Last-Modified: > >>> Originator: Dominic Fandrey > >>> Release: RELENG_7 > >>> Organization: > >> private > >>> Environment: > >> FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri > > Aug 29 23:22:22 CEST 2008 > > root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 > >>> Description: > >> When ldd is used on linux yes it invokes it instead of producing the usual > > output. > >> # pkg_info -W /compat/linux/usr/bin/yes > >> /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 > >> # sysctl compat.linux.osrelease > >> compat.linux.osrelease: 2.6.16 > >> > >> This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. > >>> How-To-Repeat: > >> # ldd /compat/linux/usr/bin/yes > > > > ldd is not going to work for Linux binaries. The Linux ldd should be used for > > Linux binaries. > > > > 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. As Rui indicated, ldd always execs binaries. It just sets environment variables that the FreeBSD runtime linker checks for. If the runtime linker sees them, it will modify it's behavior. You can achieve the same thing using env: % ldd /bin/ls /bin/ls: libutil.so.7 => /lib/libutil.so.7 (0x2808b000) libncurses.so.7 => /lib/libncurses.so.7 (0x28099000) libc.so.7 => /lib/libc.so.7 (0x280d8000) % env LD_TRACE_LOADED_OBJECTS=yes /bin/ls libutil.so.7 => /lib/libutil.so.7 (0x2808b000) libncurses.so.7 => /lib/libncurses.so.7 (0x28099000) libc.so.7 => /lib/libc.so.7 (0x280d8000) All the "ldd" printfs, etc. are actually from the runtime linker, not ldd itself. The Linux runtime linker doesn't modify it's behavior for LD_TRACE_LOADED_OBJECTS, so Linux apps just run normally when invoked by ldd. -- John Baldwin