On 05/28/2014 05:19 PM, David Kuehling wrote:
"David" == David Daney <[email protected]> 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?
It question is an example of the logical fallacy of circular reasoning.
You are asking what a mips64{,el} Debian port should do based on what
it might already would be doing.
Those library locations were established long ago by SGI.
Since there is no current mips64{,el} Debian port, and we are talking
about how a new port should do things. We have the two choices I outlined.
1) The old SGI way.
2) The new Debian way.
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.
x86 is irrelevant. Of much more importance is maintaining compatibility
with the existing 32-bit MIPS Debian Distributions (all of which run
well on 64-bit kernel/hardware)
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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
