Bug#467069: pango1.0: biarch support

[Loïc Minier]

On Sun, Feb 24, 2008, Javier Serrano Polo wrote:
> El dg 24 de 02 del 2008 a les 11:22 +0100, en/na Loïc Minier va
> escriure:
> >  Ok, but why not using usr/lib/$(DEB_HOST_GNU_TYPE)?
> 
> There's no package using usr/lib/i486-linux-gnu or
> usr/lib/x86_64-linux-gnu. Those paths are even incorrect, compilation on
> amd64 would need overriding DEB_HOST_GNU_TYPE. And I won't use ../lib32.

 I'm not sure you're aware of what multiarch is about: it's not about
 building 32-bits packages under 64-bits or vice-versa, it's about
 having parallel installable libs for all arches.  So you could even
 have an arm pango installed if you have a way to run arm binaries such
 as qemu-arm.

 The pathnames are not a pango1.0 invention, these have been agreed upon
 already; if you're running Debian, you probably have something like
 /etc/ld.so.conf.d/i486-linux-gnu or
 /etc/ld.so.conf.d/x86_64-linux-gnu.conf telling the runtime linker
 about these libs.

 (I don't understand your remark about ../lib32.)

> >  Your ld.so should
> >  find the libs and the modules should be found by pango.  What's
> >  preventing you to use the multiarch pathnames or why are you insisting
> >  on using /usr/lib32 / the biarch pathnames?
> 
> /usr/lib32 works, it's tested. It's standard. It's the one currently
> used by Debian; either this or /emul/ia32-linux/usr/lib. On the other
> hand, what's preventing the use of DEB_BUILD_OPTIONS=arch32bit? What
> packages are using usr/lib/$(DEB_HOST_GNU_TYPE)?

 As I explained in my first reponse, multiarch is a superset of biarch;
 biarch works, multiarch works; it would be quite complex to have a
 multiarch *and* a biarch version of pango, so I'd prefer not mixing
 these.

> >  Why is it needed?  (What's the rpath pointing to and why is it
> >  problematic?)
> The rpath points to /usr/lib32. That shouldn't be a problem, but lintian
> complains because rpath is deprecated in Debian. Perhaps you already
> know this:
> http://wiki.debian.org/RpathIssue

 Ok, I was wondering whether you were required to strip this RPATH to
 fix a particular runtime issue; one way to fix it is to strip it like
 you did (I would expect libtool to not generate this RPATH if it
 properly supports biarch though, but I'm not interested in
 investigating), and it's nice for policy compliance.  Yes, I know about
 the RpathIssue; the most common one is the other way around (/usr/lib64
 being considered the standard and /usr/lib RPATHes being generated)
 which causes great trouble to enforce LD_LIBRARY_PATH on amd64, but
 that's another story.

-- 
Loïc Minier