Steve Langasek <[EMAIL PROTECTED]> writes:
> On Fri, Jan 12, 2007 at 08:19:18PM +0100, Goswin von Brederlow wrote:
>> As for using /usr/lib32 on i386 that is totaly up to you. On i386
>> /usr/lib32 does not yet exist but I don't see a reason not to create
>> it. Note that you can't have system libraries in /usr/lib32 since it
>> is not a default lib dir on i486.
>
> If you're going to use non-standard paths at all, why would you not move
> this to /usr/lib/i486-linux-gnu, which is also already part of the system
> lib path in etch and is much better future-proofed than the alternatives?
Because binutils does not support /usr/lib/i486-linux-gnu and amd64
already uses lib32 (and binutils supports it there). lib32 is
standardized in the FHS:
| /lib<qual> : Alternate format essential shared libraries (optional)
| Purpose
|
| There may be one or more variants of the /lib directory on systems
| which support more than one binary format requiring separate
| libraries. [14]
|
| [14] This is commonly used for 64-bit or 32-bit support on systems
| which support multiple binary formats, but require libraries of the
| same name. In this case, /lib32 and /lib64 might be the library
| directories, and /lib a symlink to one of them.
|
| /usr/lib<qual> : Alternate format libraries (optional)
| Purpose
|
| /usr/lib<qual> performs the same role as /usr/lib for an alternate
| binary format, except that the symbolic links /usr/lib<qual>/sendmail
| and /usr/lib<qual>/X11 are not required. [26]
Anyway, the conditional use of /usr/lib32 as with the revised
ia32-hack patch posted yesterday doesn't require i386 to use
/usr/lib32 but allows amd64 to do so. That would be the savest bet.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
