Loïc Minier <[EMAIL PROTECTED]> writes:
> On Fri, Jan 12, 2007, Steve Langasek wrote:
>> 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?
>
> I'm willing to use whatever is blessed by bi-arch as I think it would
> make sense to support bi-arch in the lenny lifecycle; I think the
> adaptation that libpango needs are relatively close in both cases (but
> biarch will need a second build of course).
>
> (FYI, pango can be built with multi-arch support but
> /usr/lib/i486-linux-gnu, is then used as libdir, not just for module
> files and modules.)
Nearly right:
ifneq (,$(findstring multiarch,$(DEB_BUILD_OPTIONS)))
LIBDIR := usr/$(DEB_HOST_GNU_TYPE)/lib
Pango uses the cross-compiler dirs which binutils supports and I more
and more think is the right choice [so don't change that, it is fine].
The libc6 in etch on the other hand uses the proposed
usr/lib/$(DEB_HOST_GNU_TYPE) in /etc/ld.so.conf.d/*. That proposal was
initialy made without knowing that cross compiling had already
established usr/$(DEB_HOST_GNU_TYPE)/lib so well.
For what is worth, if libc6 changes the /etc/ld.so.conf.d/* files then
multiarch becomes usable. Native gcc and binutils both work with the
cross-compile dirs too.
> It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I
> checked lib64z1 and lib64asound2). It's less clear to me what to use
> for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use
> /emul/ia32-linux/usr/lib; is this correct? Does it make sense that use
> this path?
/usr/lib32 is a link to /emul/ia32-linux/usr/lib. Due to dpkgs link
handling you must ship files in /emul/ia32-linux/usr/lib and not in
/usr/lib32. In the code you can use /usr/lib32 or
/emul/ia32-linux/usr/lib as you wish and most, if not all, packages
use /usr/lib32.
The /emul/ia32-linux/ comes from ia64 where it denotes that 32bit
stuff needs emulation and isn't purely native code.
> --
> Loïc Minier <[EMAIL PROTECTED]>
MfG
Goswin
