Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 685946 - sys-devel/gcc: incomplete multilib dependencies (automagically depends on multilib sys-devel/zlib)
Summary: sys-devel/gcc: incomplete multilib dependencies (automagically depends on mul...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-14 11:45 UTC by Daniel M. Weeks
Modified: 2019-05-14 18:23 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel M. Weeks 2019-05-14 11:45:48 UTC
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
Comment 1 Sergei Trofimovich gentoo-dev 2019-05-14 18:15:39 UTC
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
Comment 2 Daniel M. Weeks 2019-05-14 18:23:49 UTC
(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.