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