In Fedora we provide several different packages for libraries and drivers from INDI [1] we can ship (due to patent issues).
As this requires a lot of work, I'm starting to create a single package for all libraries. I've started to do a scratch build on COPR [2] with only the libapogee library, but while working on this I discovered that running rpmlint both on new package and the one currently in Fedora repositories (libapogee) points out several errors:
`E: shared-library-without-dependency-information /usr/lib64/libapogee.so.3.2` I'm not sure if this is a rpmlint false positive. All I can found searching is an issue in rpmlint which says that the library could be statically linked [3], but running ldd on the file shows it is shared. (as far I understand, I'm not a software developer)
`E: missing-PT_GNU_STACK-section /usr/lib64/libapogee.so.3.2` I can't find anything searching for this online. Maybe another false positive?
Is there anyone that can shed some light on what's happening?Thanks Mattia
[1] https://github.com/indilib/indi-3rdparty [2] https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/3134210/ [3] https://github.com/rpm-software-management/rpmlint/issues/361
On Sat, Jan 8, 2022 at 6:37 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
`E: shared-library-without-dependency-information /usr/lib64/libapogee.so.3.2` I'm not sure if this is a rpmlint false positive. All I can found searching is an issue in rpmlint which says that the library could be statically linked [3], but running ldd on the file shows it is shared. (as far I understand, I'm not a software developer)
I see this happen with libraries that do not depend on any symbols in libc. Check pretty much any ocaml-* package, for example, and rpmlint will report this. If your library functions as expected, then ignore this message.
`E: missing-PT_GNU_STACK-section /usr/lib64/libapogee.so.3.2` I can't find anything searching for this online. Maybe another false positive?
This means that the toolchain thinks your library needs an executable stack. That usually happens because the project includes assembly language files, and those files do not contain the magic to tell the toolchain that the stack does not need to be executable. Try adding -Wa,--noexecstack to the build flags or -Wl,-z,noexecstack to the linker flags.
Il 08/01/22 23:41, Jerry James ha scritto:
On Sat, Jan 8, 2022 at 6:37 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
`E: shared-library-without-dependency-information /usr/lib64/libapogee.so.3.2` I'm not sure if this is a rpmlint false positive. All I can found searching is an issue in rpmlint which says that the library could be statically linked [3], but running ldd on the file shows it is shared. (as far I understand, I'm not a software developer)
I see this happen with libraries that do not depend on any symbols in libc. Check pretty much any ocaml-* package, for example, and rpmlint will report this. If your library functions as expected, then ignore this message.
`E: missing-PT_GNU_STACK-section /usr/lib64/libapogee.so.3.2` I can't find anything searching for this online. Maybe another false positive?
This means that the toolchain thinks your library needs an executable stack. That usually happens because the project includes assembly language files, and those files do not contain the magic to tell the toolchain that the stack does not need to be executable. Try adding -Wa,--noexecstack to the build flags or -Wl,-z,noexecstack to the linker flags.
Thanks, indeed the project itself sets those flags in a cmake module for both the build and linker flags. I originally avoided to have the project set custom flags because it also sets -fPIE and that caused build failures.
But after having removed only the -fPIE from the custom flags, I get the same errors from rpmlint.
Mattia