On Tue, 16 Apr 2013 15:34:40 +0400
Игорь Пашев <pashev.igor@gmail.com> wrote:
> Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
> use constant DEFAULT_LIBRARY_PATH =>
> qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
> /emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
>
> and adds multiarch dirs only for crosscompiling:
>
> if ($crossprefix) {
> push @crosslibrarypaths, "/lib/$multiarch", "/usr/lib/$multiarch",
> "/$crossprefix/lib", "/usr/$crossprefix/lib",
> "/$crossprefix/lib32", "/usr/$crossprefix/lib32",
> "/$crossprefix/lib64", "/usr/$crossprefix/lib64";
> }
i.e. when cross-compiling, the foreign architecture object files need
to be linked against the shared libraries of the same architecture.
Dpkg::Shlibs is used in package building, not at runtime.
The value of $multiarch depends on the architecture being built.
($crossprefix is the old dpkg-cross style path)
> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
> and put them in first positions.
Why?
AFAICT, the only time ordering is going to matter is if libfoo1 is not
multiarch and libfoo2 is multiarch, both are installed for the current
dpkg build architecture and you are building something which compiles
against both versions. That's a false premise because, currently, the
-dev side of MultiArch isn't complete and even if foo builds
libfoo2-dev and libfoo1-dev still exists, libfoo1-dev and libfoo2-dev
will not be co-installable. So the actual .so symlink will be for
whichever one gets installed. The mere fact that one version is
multiarch and one is not is incidental to this "problem".
When calculating the shlibs of a package during the build, the libfoo
part of the dependency is not relevant, it is the libfoo?-dev package
which determines which .so symlink gets used and therefore which libfoo
gets linked.
This is a topic for the debian-dpkg list, please follow up there.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgpfpL03bBVwH.pgp
Description: PGP signature