Loïc Minier <[EMAIL PROTECTED]> writes:
> On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
>> 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].
>
> Yes, we already discussed this in the multiarch bug report and this is
> changed in SVN since a couple of days (it was on the TODO list since
> back then,
>
> <http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/pango1.0/debian/rules?op=file&rev=0&sc=0>).
>
> You told me both should work and I heard from other folks that the
> correct dir for multiarch was the usr/lib/$(DEB_HOST_GNU_TYPE) case.
>
> Who's the authority to decide on such things? Should I contact the
> binutils maintainer to get the final word? There shouldn't be room for
> doubt here. :-/
>
> I prefer using the blessed official / canonical dir for multiarch as
> the goal is to achieve multiarch, not a cross-compiling pango.
I guess the binutils, gcc and glibc folks have to get together and
decide. But cross compiling has been around for a while so any new
thing (like multiarch) should follow the beaten path. I just wish I
had realized a year ago that standard binutils already searches in the
cross compile dirs.
>> 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.
>
> So, both work currently; why not keep the scheme of the libc if it's
> supported and blessed as "multiarch"? Was it decided to revert this?
No, binutils does not support /usr/lib/$(DEB_HOST_GNU_TYPE). If you
put libraries there stuff fails to link. And that needs a source
change in binutils. On the other hand the change in libc6 is just the
special conffile debian creates.
>> > 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.
>
> Hmm. Ok; so I'll use /usr/lib32, and you'll ship files in /emul.
Perfect.
So lets solve this problem now and leave the multiarch issues for Lenny.
MfG
Goswin
