Date: Wed, 31 Jul 2013 13:42:24 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Gennady Proskurin <gprspb@mail.ru>, Mateusz Guzik <mjguzik@gmail.com>, Mark Johnston <markj@freebsd.org> Subject: Re: ldd runs linux programs Message-ID: <201307311342.24273.jhb@freebsd.org> In-Reply-To: <51F8B05E.5030003@freebsd.org> References: <20130728193110.GB17514@gpr.nnz-home.ru> <20130729205449.GA6007@dft-labs.eu> <51F8B05E.5030003@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, July 31, 2013 2:36:14 am Julian Elischer wrote: > On 7/30/13 4:54 AM, Mateusz Guzik wrote: > > On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: > >>> 127276 suggests running the binary as is (which I don't like) and > >>> achieves this with a hacky way. So if we really want to do this, the > >>> patch should be reworked to detect Linux binaries properly. > >>> > >>> In general we should gain linux_ldd (like linux_kdump) and our ldd > >>> should work only on FreeBSD binaries. The last part is achieved with my > >>> patch. > >>> > >>> markj, are you working on this? > >> Not really; my original fix for this problem was essentially the same as > >> yours. That is, just change ldd(1) to bail if the OS ABI byte isn't > >> equal to ELFOSABI_FREEBSD. That's the change I have committed in my > >> local tree right now. > >> > >> Then I thought I'd try to get ldd to work properly with Linux binaries > >> as well, but wasn't sure what the right approach should be. As the above > >> PR suggests, the easy thing to do is to just pass > >> LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit > >> ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, > >> but I didn't really see another approach. > >> > >> That said, I think your patch should be committed since it's clearly an > >> improvement over the current behaviour. I'm willing to test and commit > >> it, and clean up the open PRs. If you could expand on the right way to > >> handle Linux binaries, I'd be willing to implement and commit that too. > >> I don't quite understand your reference to linux_kdump though - I have > >> no such program on my laptop running CURRENT, and ktrace+kdump seem to > >> work fine with the Linux binaries under /compat/linux. > >> > > Well, there was linux_kdump in ports but it apparently got obsolete as > > necessary support for included in our regular kdump. > > > > So it may make sense to teach our ldd how to deal with Linux binaries > > for consistency, but its unclear for me if this is better than providing > > linux_ldd. Also there is the problem of (not) appending /compat/linux to > > printed paths (for Linux binaries the kernel performs file lookups against > > /compat/linux first). I'm not that interested in this problem though. :P > > > > That being said, if you want to do something with this, I suggest > > cleaning up PRs and reviving discussion in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127276 > > if linux binaries are installed then chain to libexec/linux-ldd just > like fsck chains to various specific fsck binaries. If there is no > such chain loadable ldd, then just refuse to do anything. That is not how ldd works. ldd always runs the program. It is the program (specifically the rtld of the new program) which changes its behavior based on environment variables. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307311342.24273.jhb>