Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?
+++ Neil Williams [2013-04-16 13:29 +0100]:
> On Tue, 16 Apr 2013 16:11:24 +0400
> Игорь Пашев <firstname.lastname@example.org> wrote:
> > /lib:/usr/lib was the default path, now it is
> > /lib/<multiarch>:/usr/lib/<multiarch>, isn't it?
> No - there's confusion here between the runtime link path and the
> build time link path. Dpkg::Shlibs at the point quoted is concerned
> with the build time paths.
> The implementation of MultiArch for -dev packages is
> not complete and most -dev packages are not co-installable with a
> foreign architecture of the same -dev package.
> MultiArch in Debian is principally concerned with runtime paths, the
> build-time paths and consequent cross-compilation support still has a
> few wrinkles to resolve.
Despite most -dev packages not yet using multiarch paths, some have been,
and more will be (co-installability of -dev packages of multiple
architectures is needed for some builds: libpaper was the first one I
came across, but there will be many more as we move up the stack to
packages with more complex build-deps, such as desktop stuff).
So in general it is a good idea if software checks the multiarch paths
at build time as well as at runtime. And it should check the multiarch
paths before the generic paths as that reduces the risk of getting the
The multiarch spec has indeed not been updated to reflect best
practice for -dev package multiarching, but that's not because it's
not a good idea, or will never happen, it's just a combination of
general slackness and the Debian release cycle timing, (which meant we
only targetted the essential runtime multiarch stuff to wheezy).
So in general it seems like a good idea to me for dpkg shlibs to check
multiarch paths at build time if it doesn't already, because it'll
need to soon. I am of course happy to hear of reasons why that will
break things and we should not do it yet.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM