Hi, On Wed, Sep 14, 2011 at 10:11:14PM +0200, Yann Dirson wrote: > Now that I'm looking at it, I realize that the default "make install" > does install libfakeroot.so directly in $prefix/lib/ - this brings me > back to the question of why we need to get it out of the standard > ld.so search path, especially if anyone installing from source get it > in that very search path. > > Let's keep in mind that if we do the same, there is no problem to be > solved for PATHS: this variable won't be useful at all any more, since > ld.so would do for us that job it does well for others ;) > > But if we still need that libfakeroot/ dir, looks like we need > something to make sure we have a fixed string where we currently have > @libdir@ - an auxiliary @scriptlibdir@ would do the trick. A > configure flag to toggle multiarch mode, which would also check > dpkg-architecture and set @libdir@ and @scriptlibdir@ accordingly.
What is the reasoning behind using the libfakeroot/ directory? For example as fakeroot is not yet installed into the multiarch /usr/lib/<triplet>/ directory, to make qemu find it when emulating foreign architectures, I will manually download the foreign fakeroot deb package and copy libfakeroot-sysv.so into /usr/lib/<triplet>/. The linker will NOT search in /usr/lib/<triplet>/libfakeroot and I tried playing with LD_PRELOAD but wasnt able to instruct it to look into the libfakeroot/ subdirectory as well. I'm probably overlooking the obvious but unless someone knows how to make it automatically look into /usr/lib/<triplet>/libfakeroot as well it would certainly be better to have libfakeroot-sysv.so in the standard path /usr/lib/<triplet>/. This is where my foreign libfakeroot-sysv.so currently resides and it works well. just my two cents. What is the status on multiarch-ing fakeroot? cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
