Comment 6 for bug 2031495

My current state of investigation is that the new dependency to libgcc_s.so.1 exposes a bug in the code building the testroot: it basically copies the few .so dependencies of a test binary into the testroot using the path as exposed by ld.so. However, that path doesn't necessarily match the ld.so search path due to usr-merge.

AFAICT it wasn't a problem so far, because there was no actual dependency on libgcc_s.so.1 in the tests themselves, until the new flags added the dep for some architectures, notably armhf. And it only fails on the -prof variant because the standard slibdir is /lib, so ld.so would still find the lib, but -prof changes slibdir to its own -prof subdirectory.

Now, I still don't know why it fails in the autopkgtests but the build itself passes. Might be from different filesystems being used, or just whatever syscall is used to compute said path behaves differently on an armhf kernel vs an arm64. I'm still trying to figure out where in the code the path is first computed, to see if it's easily fixable there, but an alternative solution would be to detect a usr-merged system when building the testroot, and mirror it there.