Bug 1643079

Summary: Does not link against glibc on Rawhide
Product: [Fedora] Fedora Reporter: Vitaly <vitaly>
Component: rpmlintAssignee: Tom "spot" Callaway <spotrh>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 31CC: davejohansen, dmalcolm, fweimer, igor.raits, jakub, j, jwakely, law, mpolacek, msebor, nickc, tmz, twoerner, vascom2, vitaly
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-11 18:15:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Build log in Rawhide none

Description Vitaly 2018-10-25 13:23:32 UTC
Description of problem:
Does not link against glibc on Rawhide.

Version-Release number of selected component (if applicable):
8.2.1-4.fc30.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Build SRPM https://xvitaly.fedorapeople.org/for-review/google-benchmark-1.4.1-1.fc28.src.rpm in Rawhide's mock.
2. Check ldd libbenchmark_main.so.0.0.0.
3.

Actual results:
ldd libbenchmark_main.so.0.0.0
        linux-vdso.so.1 (0x00007ffd432c3000)
        libbenchmark.so.0 => not found

Expected results:
libbenchmark_main.so.f28:
        linux-vdso.so.1 (0x00007fffa1dd6000)
        libbenchmark.so.0 => not found
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007efe4fada000)
        librt.so.1 => /lib64/librt.so.1 (0x00007efe4f8d2000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007efe4f540000)
        libm.so.6 => /lib64/libm.so.6 (0x00007efe4f1ac000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007efe4ef94000)
        libc.so.6 => /lib64/libc.so.6 (0x00007efe4ebd5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007efe4fefb000)

libbenchmark_main.so.f29:
        linux-vdso.so.1 (0x00007ffe7f19d000)
        libbenchmark.so.0 => not found
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa665a17000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fa66580f000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa66547d000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa6650e9000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa664ed1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa664b12000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa665e38000)

Additional info:

Comment 1 Florian Weimer 2018-10-25 13:39:32 UTC
Do you have a build log for inspection?  Thanks.

Comment 2 Jakub Jelinek 2018-10-25 13:46:31 UTC
Doesn't redhat-rpm-config enable --as-needed?  That could be the result of that flawed https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking

Comment 3 Vitaly 2018-10-25 13:53:10 UTC
Created attachment 1497475 [details]
Build log in Rawhide

Added build log.

Comment 4 Vitaly 2018-10-25 13:54:48 UTC
Rpmlint output:

google-benchmark.x86_64: E: library-not-linked-against-libc /usr/lib64/libbenchmark_main.so.0.0.0

Comment 5 Florian Weimer 2018-10-25 14:20:32 UTC
(In reply to Jakub Jelinek from comment #2)
> Doesn't redhat-rpm-config enable --as-needed?  That could be the result of
> that flawed https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking

Agreed.  libbenchmark_main.so.0.0.0 is special: it really does not have to be linked against libc.so.6 because it does not reference any libc symbols.  This never happens for executables because the statically linked startup code references __libc_start_main, but for DSOs, it can happen.  But it is also a constant source of problems (using libc symbols without linking to the relevant libraries breaks symbol versioning), so the rpmlint check makes some sense here.

I'm not sure what to do with this bug.  It's clearly not something we need to fix in glibc.

Comment 6 Ben Cotton 2019-08-13 19:14:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 7 Fedora Admin user for bugzilla script actions 2020-06-03 02:57:02 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 8 Ben Cotton 2020-11-03 15:03:53 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.