Bug 1661512

Would it be possible to add --g-libs support to rawhide at least?  Thanks.

Added in rpm-4.14.2.1-5.fc31

Sorry, the patch does not work with the version of file in rawhide:

<mock-chroot> sh-5.0# file -bi /lib64/ld-2.29.9000.so 
application/x-pie-executable; charset=binary

/lib64/ld-2.29.9000.so does not have the PIE flag set:

<mock-chroot> sh-5.0# readelf -dW /lib64/ld-2.29.9000.so

Dynamic section at offset 0x29df0 contains 21 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             Library soname: [ld-linux-x86-64.so.2]
 0x0000000000000004 (HASH)               0x2f0
 0x000000006ffffef5 (GNU_HASH)           0x3c8
 0x0000000000000005 (STRTAB)             0x810
 0x0000000000000006 (SYMTAB)             0x4c8
 0x000000000000000a (STRSZ)              564 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x2af80
 0x0000000000000002 (PLTRELSZ)           192 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0xf40
 0x0000000000000007 (RELA)               0xb38
 0x0000000000000008 (RELASZ)             1032 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)             0xa90
 0x000000006ffffffd (VERDEFNUM)          5
 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
 0x000000006ffffff0 (VERSYM)             0xa44
 0x000000006ffffff9 (RELACOUNT)          41
 0x0000000000000000 (NULL)               0x0

So it the output of file is clearly wrong.  I think we really need to investigate how we can use something more reliable than file for ELF processing.

If output of file is wrong, that doesn't make the rpm patch wrong.

As for better identification of ELF objects, I'm sure everybody agrees. There's a bug for it already: 
https://bugzilla.redhat.com/show_bug.cgi?id=1609013

The problem is that I for one sure don't know how to distinguish a DSO library that is actually executable (both in permissions and having a main()) from a PIE executable, and seems file authors dont either. If somebody knows, patches welcome...

file isn't completely wrong. ld.so is an executable that is dynamically linked (so it is also a library).
Independently from the fact that we do need a better "file classifier" we might need to better define/document what -g-libs means in this case.
glibc is kind of special in that it has multiple shared libraries that are also executables:

$ file /usr/lib64/libc-2.28.so 
/usr/lib64/libc-2.28.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=245853cc14fc438740d392e5a6a4a3b5e95720e7, for GNU/Linux 3.2.0, not stripped, too many notes (256)

$ /usr/lib64/libc-2.28.so
GNU C Library (GNU libc) stable release version 2.28.
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 8.3.1 20190223 (Red Hat 8.3.1-2).
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Current Fedora binutils sets the PIE flag on PIE executables, so we have a reliable way of detecting them during the build.  Neither object you mention has this flag set.

Maybe file cannot use it in file proper, but we definitely can use it to control debuginfo stripping for Fedora builds if we write our own tool.

Mark, any suggestions how to proceed here?  Should pick up eu-elfclassify again and update find-debuginfo.sh to use it if it is available?  Thanks.

(In reply to Florian Weimer from comment #7)
> Mark, any suggestions how to proceed here?  Should pick up eu-elfclassify
> again and update find-debuginfo.sh to use it if it is available?  Thanks.

Yes, I think we should. Sorry for dropping the ball on eu-elfclassify. I do think it is a good idea.
We should pick it up again. And see if we can get some rpm hacker to look at it, to see if they are happy to use it instead of parsing 'file' output.
Hint, rpm maintainers, could you take a peek at the following thread:
https://sourceware.org/ml/elfutils-devel/2019-q2/msg00018.html

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Any status on this bug? It blocks using this functionality downstream.

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.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Reassigning to debugedit now that it's a separate component.

We don't need this anymore for the glibc build. We use a wrapper now that inhibits debuginfo separation for ld.so, and use the default for everything else.