Bug#467069: pango1.0: biarch support
Loïc Minier
lool at dooz.org
Mon Feb 25 10:17:31 UTC 2008
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
More information about the pkg-gnome-maintainers
mailing list