gcc (by way of toolchain.eclass) depends on zlib. However, if ABI_X86="32 64" is set at build time, 32-bit gfortran gets linked against 32-bit but the dependency isn't tracked. This can cause breakage later if gcc is built as a binary package or zlib is rebuilt with ABI_X86=64. Fortunately, this gets picked up by revdep-rebuild and portage: * Broken files that require: libz.so.1 (32 bits) * /usr/lib64/gcc/x86_64-pc-linux-gnu/8.3.0/32/libgfortran.so.5.0.0 * Assign files to packages * /usr/lib64/gcc/x86_64-pc-linux-gnu/8.3.0/32/libgfortran.so.5.0.0 -> sys-devel/gcc-8.3.0-r1 >>> package: sys-libs/zlib-1.2.11-r2 * - /usr/lib32/libz.so.1 * - /usr/lib32/libz.so.1.2.11 * used by /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/32/libgfortran.so.5.0.0 (sys-devel/gcc-8.3.0-r1) Reproducible: Always
Oh, interesting. It's a bit complicated to express multilib dependencies in gcc due to USE=multilib/ABI_${ARCH} mismatch thus it will take a while to fix properly. I'm surprised to see zlib used in gfortran. It might be a redundant dependency as 9.1.0 does not seem to have it: $ lddtree /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/32/libgfortran.so /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/32/libgfortran.so (interpreter => None) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/32/libquadmath.so.0 libz.so.1 => /usr/lib32/libz.so.1 libm.so.6 => /lib32/libm.so.6 ld-linux.so.2 => /lib64/ld-linux.so.2 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/32/libgcc_s.so.1 libc.so.6 => /lib32/libc.so.6 $ lddtree /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/32/libgfortran.so /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/32/libgfortran.so (interpreter => None) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/32/libquadmath.so.0 libm.so.6 => /lib32/libm.so.6 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/32/libgcc_s.so.1 libc.so.6 => /lib32/libc.so.6 ld-linux.so.2 => /lib64/ld-linux.so.2
(In reply to Sergei Trofimovich from comment #1) > Oh, interesting. It's a bit complicated to express multilib dependencies in > gcc due to USE=multilib/ABI_${ARCH} mismatch thus it will take a while to > fix properly. It certainly surprised me and I see the complexity. It's a pretty minor problem to work around but I wanted to make sure it's know. > > I'm surprised to see zlib used in gfortran. It might be a redundant > dependency as 9.1.0 does not seem to have it: That's interesting. I checked a system with 7.3.0 and it's also not linked against zlib.
Is this still the case?
