Why does dpkg-shlibdeps look at the target architecture?

[Helmut Grohne <helmut@subdivi.de>]

Hello Guillem and Raphaël,

I sat down with Samuel yesterday and we looked into bootstrapping 
hurd-amd64 on amd64. Doing cross-kernel same-cpu bootstraps is something 
that is not expected to just work as the resulting binaries are not 
quite distinguishable from looking at ELF headers, yet we tried.

It failed installing the full gcc cross compiler, because 
cpp-14-x86-64-gnu had an unsatisfiable dependency on libc0.3. This was 
issued by dpkg-shlibdeps, because it considered libc0.3 for libm.so.6. I 
note that cpp-14-x86-64-gnu is Architecture: amd64 and that libc0.3 was 
not qualified :hurd-amd64, so that dependency is never satisfiable.

In Dpkg/Shlibs.pm in sub setup_library_paths, there is the following 
code:

| # Adjust set of directories to consider when we're in a situation of a
| # cross-build or a build of a cross-compiler.
| my $multiarch;
|
| # Detect cross compiler builds.
| if ($ENV{DEB_TARGET_GNU_TYPE} and
|     ($ENV{DEB_TARGET_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}))
| {
|     $multiarch = gnutriplet_to_multiarch($ENV{DEB_TARGET_GNU_TYPE});
| }
| # Host for normal cross builds.
| if (get_build_arch() ne get_host_arch()) {
|     $multiarch = debarch_to_multiarch(get_host_arch());
| }
| # Define list of directories containing crossbuilt libraries.
| if ($multiarch) {
|     push @system_librarypaths, "/lib/$multiarch", "/usr/lib/$multiarch";
| }
|
| push @system_librarypaths, DEFAULT_LIBRARY_PATH;

It is not clear to us, why that first branch exists. It was originally 
added by Raphaël in support of cross compilation and later changed a 
couple of times.

I attempted a full architecture cross bootstrap (for m68k as it is 
quick) with that first branch deleted and it succeeded. I also attempted 
a hurd-amd64 bootstrap on amd64 with it deleted and then 
cpp-14-x86-64-gnu become installable.

Let me also point out that the gcc packaging prefixes invocations of 
dh_shlibdeps issued for its libraries with $(cross_shlibdeps) and also 
passes library search paths. That variable is defined as

| cross_shlibdeps =  DEB_HOST_ARCH=$(TARGET) ARCH=$(DEB_TARGET_ARCH) MAKEFLAGS="CC=something"

for cross toolchain builds. We may conclude that the relevant branch in 
Shlibs.pm never becomes relevant during a gcc build as the second branch 
always overwrites $multiarch.

Remember that since target libraries are not target qualified in the 
resulting Depends, they're never satisfied in the desired way.

We would like to better understand why we even consider them in 
Shlibs.pm and if the reason is not convincing whether that branch could 
be deleted as it appears to improve cross bootstrap.

Thanks for sharing what you know about this matter

Helmut