Date: Fri, 5 Feb 2016 08:34:57 -0700 From: Warner Losh <imp@bsdimp.com> To: Ben Morrow <ben@morrow.me.uk> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: Re: mips/qemu jails with native-xtools Message-ID: <CANCZdfpuPtiK0d8UfDrD1WA0r_ossC3ug2F_RP-scR57noDb5w@mail.gmail.com> In-Reply-To: <20160205143335.GC93874@anubis.morrow.me.uk> References: <20160205143335.GC93874@anubis.morrow.me.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 5, 2016 at 7:33 AM, Ben Morrow <ben@morrow.me.uk> wrote: > [Sorry, I sent this to Warner privately by mistake.] > > Warner Losh <imp@bsdimp.com> wrote: > > On Thu, Feb 4, 2016 at 5:26 PM, Ben Morrow <ben@morrow.me.uk> 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? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpuPtiK0d8UfDrD1WA0r_ossC3ug2F_RP-scR57noDb5w>