>>>>> "David" == David Daney <ddaney.cavm@gmail.com> writes: > On 05/27/2014 06:58 PM, Yunqiang Su wrote: >> Sorry for dig it out again :-( >> >> If we put o32 multilib libraries in to /usr/lib directly, it will >> make lots of packages ftbfs, if they use -L/usr/lib. >> >> For this problem, we have another option that is: >> >> put ld.so.1 for o32 still in /lib while put other libraries to >> /usr/libo32 and /libo32. > As has been said many times before, there are already standard > locations established for libraries on MIPS systems. > 32-bit o32 ABI -> /lib, /usr/lib > 64-bit n32 ABI -> /lib32, /usr/lib32 > 64-bit n64 ABI -> /lib64, /usr/lib64 Are you sure that these "standard" locations apply to the mips64el debian port? I think Yunqiang is talking about mips64el systems and not Debian mipsel in general. Using /usr/lib only for the native mips64el libraries seems to be consistent with how things are handled on x86_64. What would you suggest WRT the build failures that Yunqiang mentioned? Do we now need to file bugs against all packages that assume that one or another library resides in /usr/lib? That might slow down the porting efforts a lot. > The new Debian way of doing things puts things in directories something like: > /lib/mips-linux-gnu > /lib/mips64-linux-gnuabi64 > /lib/mips64-linux-gnuabin32 This would at least keep o32 libraries out of /usr/lib. Yunqiang, any problems with switching to these directories? David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F
Attachment:
pgpbitleEBrbq.pgp
Description: PGP signature