From owner-freebsd-mips@freebsd.org Fri Feb 5 14:33:42 2016 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F67EA76F18 for ; Fri, 5 Feb 2016 14:33:42 +0000 (UTC) (envelope-from mauzo@morrow.me.uk) Received: from arha.morrow.me.uk (arha.morrow.me.uk [176.58.88.145]) by mx1.freebsd.org (Postfix) with ESMTP id 50729196D for ; Fri, 5 Feb 2016 14:33:41 +0000 (UTC) (envelope-from mauzo@morrow.me.uk) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by arha.morrow.me.uk (Postfix) with ESMTPSA id 92D91B0B81 for ; Fri, 5 Feb 2016 14:33:39 +0000 (GMT) Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 39A751728D; Fri, 5 Feb 2016 14:33:36 +0000 (GMT) Date: Fri, 5 Feb 2016 14:33:35 +0000 From: Ben Morrow To: freebsd-mips@freebsd.org Subject: Fwd: Re: mips/qemu jails with native-xtools Message-ID: <20160205143335.GC93874@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:33:42 -0000 [Sorry, I sent this to Warner privately by mistake.] Warner Losh wrote: > On Thu, Feb 4, 2016 at 5:26 PM, Ben Morrow wrote: > > > I've finally got a mips/qemu poudriere jail working properly with a > > native toolchain, but it took a bit of fiddling to make it work, so I > > thought I'd report on what I did. [...] > > Having put the proper libraries back, the next problem was that ld was > > failing to find shared libraries that were implicitly linked (DT_NEEDED) > > by other shared libraries. The specific port I was building was > > net/tshark, which links glib, which implicitly pulls in libpcre and > > libiconv. The configure step was failing because ld couldn't find > > libpcre.so.3. > > > > It turns out that ld finds the path to search for DT_NEEDED libraries by > > reading ld-elf.so.hints. That file (in the jail) is BE, because this is > > a mips world with a mips ldconfig, but the ld binary is LE, so it can't > > read the file. With the patch below, it can; since endianness is the > > only difference between architectures, I think it should be safe for > > general use, but I don't really know > > I'd think it would be better to generate the ld.so in the proper binary > format. How hard is that? ld.so has to be a mips binary, otherwise we can't run any other (non-static) mips binaries. So ld.so.hints has to be in BE format, otherwise ld.so can't read it. The problem is that ld and ld.so have different endiannesses, and ld is assuming it can read ld.so's files to find the search path. Of course, it would always be possible to simply use a mips binary for ld, as well, and just let it be emulated. Ben