From owner-freebsd-mips@freebsd.org Fri Feb 5 21:04:00 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 ED83AA9E03A for ; Fri, 5 Feb 2016 21:04:00 +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 BF63D937 for ; Fri, 5 Feb 2016 21:04:00 +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 9CF07B0B2E; Fri, 5 Feb 2016 21:03:56 +0000 (GMT) Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id BD49E172F2; Fri, 5 Feb 2016 21:03:52 +0000 (GMT) Date: Fri, 5 Feb 2016 21:03:51 +0000 From: Ben Morrow To: Warner Losh Cc: "freebsd-mips@freebsd.org" Subject: Re: Re: mips/qemu jails with native-xtools Message-ID: <20160205210351.GD93874@anubis.morrow.me.uk> References: <20160205143335.GC93874@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 21:04:01 -0000 Warner Losh wrote: > On Fri, Feb 5, 2016 at 7:33 AM, Ben Morrow wrote: > > 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. > > I guess I'm misunderstanding something. When / how is ld have a different > endianness? Is it the amd64 ld that produces binaries for big-endian mips > that introduces the cross-threading? Yes, exactly. Ben