Date: Fri, 5 Feb 2016 14:33:35 +0000 From: Ben Morrow <ben@morrow.me.uk> To: freebsd-mips@freebsd.org Subject: Fwd: Re: mips/qemu jails with native-xtools Message-ID: <20160205143335.GC93874@anubis.morrow.me.uk>
next in thread | raw e-mail | index | archive | help
[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. Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160205143335.GC93874>