Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
Michael J Gruber wrote: > chmod +x'ing should be fine on Fedoras, as well. It used to be mandatory, even, exactly because of the dependency generator requiring it back then. Nowadays, you will get away with both +x or -x. The idea that shared libraries should not be executable comes from Debian, which made that a requirement after someone tried to execute a shared library and it would just crash with a segfault or something, then blaming Debian for the "broken executable". So the Debian packagers would file bugs against build system maintainers and the build systems would try to implement this then, breaking things for Fedora in the process. (E.g., we had that issue with CMake.) So then Fedora packagers would file bugs requesting that this be reverted, and upstreams would either just give up and arbitrarily decide for one or the other approach, or do what CMake did and make this configurable (and CMake even tries to auto-detect the distro and set the default for the option accordingly). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
Am Do., 15. Feb. 2024 um 17:43 Uhr schrieb Kalev Lember : > > On Thu, Feb 15, 2024 at 5:30 PM Michael J Gruber > wrote: >> >> Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against >> the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch >> builds for fc39 and el9 yields >> >> libmupdf.so.23.10()(64bit) >> >> in both cases. I could try and stuff %__elf_provides into the spec for >> a koji scratch debug run ... > > > Is libmupdf.so.23.10 executable? It used to be the case that the elf depgen > only ran on executable files, IIRC. Maybe that has changed in recent Fedoras, > but still is the case in el9? Gotcha! You rock! Thanks a bunch. chmod +x'ing should be fine on Fedoras, as well. And from looking at /usr/lib64 it's common anyways. Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
On Thu, Feb 15, 2024 at 5:30 PM Michael J Gruber wrote: > Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against > the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch > builds for fc39 and el9 yields > > libmupdf.so.23.10()(64bit) > > in both cases. I could try and stuff %__elf_provides into the spec for > a koji scratch debug run ... > Is libmupdf.so.23.10 executable? It used to be the case that the elf depgen only ran on executable files, IIRC. Maybe that has changed in recent Fedoras, but still is the case in el9? -- Kalev -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
Am Do., 15. Feb. 2024 um 17:22 Uhr schrieb Petr Pisar : > > V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a): > > Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar : > > > > > > V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a): > > > > Hi there > > > > > > > > I recently switched mupdf to shared libraries. During test builds on > > > > COPR for EPEL I noticed a strange difference to fedora builds which I > > > > can reproduce with koji scratch builds as well (epel9 vs fc39). The > > > > difference is in the automatic provides for the -libs sub package: > > > > > > > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9 > > > > > > > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39 > > > > mupdf-libs(x86-64) = 1.23.10-2.fc39 > > > > > > > > And, of course, packages built against mupdf-devel automatically > > > > require ibmupdf.so.23.10()(64bit) and fail to install on *EL. > > > > > > > > I even tested with `%ldconfig_scriptlets libs`, which makes no > > > > difference. > > > > > > > > Both packages have the same file contents including the lib, the > > > > SONAME is `libmupdf.so.23.10`. > > > > > > > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion > > > about > > > rpmbuild not to generate provides and requires for a SONAME if the libary > > > is > > > not installed into a standard library path. > > > > It's in /usr/lib64/ in both cases (x86_64, checked with > > rpmdev-extract). spec part is: > > > Does running a dependency generator for ELF files on that file report the > expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There > should be a ".../elfdeps --provides" command for generating provides. Take > that command and pass the library file as a possitional argument. An example: > > /usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301 > libacl.so.1(ACL_1.0)(64bit) > libacl.so.1(ACL_1.1)(64bit) > libacl.so.1(ACL_1.1)(64bit) > libacl.so.1(ACL_1.2)(64bit) > libacl.so.1(ACL_1.2)(64bit) > libacl.so.1()(64bit) Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch builds for fc39 and el9 yields libmupdf.so.23.10()(64bit) in both cases. I could try and stuff %__elf_provides into the spec for a koji scratch debug run ... Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a): > Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar : > > > > V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a): > > > Hi there > > > > > > I recently switched mupdf to shared libraries. During test builds on > > > COPR for EPEL I noticed a strange difference to fedora builds which I > > > can reproduce with koji scratch builds as well (epel9 vs fc39). The > > > difference is in the automatic provides for the -libs sub package: > > > > > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9 > > > > > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39 > > > mupdf-libs(x86-64) = 1.23.10-2.fc39 > > > > > > And, of course, packages built against mupdf-devel automatically > > > require ibmupdf.so.23.10()(64bit) and fail to install on *EL. > > > > > > I even tested with `%ldconfig_scriptlets libs`, which makes no difference. > > > > > > Both packages have the same file contents including the lib, the > > > SONAME is `libmupdf.so.23.10`. > > > > > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion > > about > > rpmbuild not to generate provides and requires for a SONAME if the libary is > > not installed into a standard library path. > > It's in /usr/lib64/ in both cases (x86_64, checked with > rpmdev-extract). spec part is: > Does running a dependency generator for ELF files on that file report the expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There should be a ".../elfdeps --provides" command for generating provides. Take that command and pass the library file as a possitional argument. An example: /usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301 libacl.so.1(ACL_1.0)(64bit) libacl.so.1(ACL_1.1)(64bit) libacl.so.1(ACL_1.1)(64bit) libacl.so.1(ACL_1.2)(64bit) libacl.so.1(ACL_1.2)(64bit) libacl.so.1()(64bit) -- Petr signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
>
> V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > Hi there
> >
> > I recently switched mupdf to shared libraries. During test builds on
> > COPR for EPEL I noticed a strange difference to fedora builds which I
> > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > difference is in the automatic provides for the -libs sub package:
> >
> > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> >
> > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > mupdf-libs(x86-64) = 1.23.10-2.fc39
> >
> > And, of course, packages built against mupdf-devel automatically
> > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> >
> > I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> >
> > Both packages have the same file contents including the lib, the
> > SONAME is `libmupdf.so.23.10`.
> >
> Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about
> rpmbuild not to generate provides and requires for a SONAME if the libary is
> not installed into a standard library path.
It's in /usr/lib64/ in both cases (x86_64, checked with
rpmdev-extract). spec part is:
```
%files libs
%license COPYING
%{_libdir}/%{libname}.so.%{soname}
```
Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL
V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a): > Hi there > > I recently switched mupdf to shared libraries. During test builds on > COPR for EPEL I noticed a strange difference to fedora builds which I > can reproduce with koji scratch builds as well (epel9 vs fc39). The > difference is in the automatic provides for the -libs sub package: > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9 > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39 > mupdf-libs(x86-64) = 1.23.10-2.fc39 > > And, of course, packages built against mupdf-devel automatically > require ibmupdf.so.23.10()(64bit) and fail to install on *EL. > > I even tested with `%ldconfig_scriptlets libs`, which makes no difference. > > Both packages have the same file contents including the lib, the > SONAME is `libmupdf.so.23.10`. > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about rpmbuild not to generate provides and requires for a SONAME if the libary is not installed into a standard library path. -- Petr signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Provides: libmupdf.so.23.10()(64bit) missing on *EL
Hi there I recently switched mupdf to shared libraries. During test builds on COPR for EPEL I noticed a strange difference to fedora builds which I can reproduce with koji scratch builds as well (epel9 vs fc39). The difference is in the automatic provides for the -libs sub package: Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9 Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39 mupdf-libs(x86-64) = 1.23.10-2.fc39 And, of course, packages built against mupdf-devel automatically require ibmupdf.so.23.10()(64bit) and fail to install on *EL. I even tested with `%ldconfig_scriptlets libs`, which makes no difference. Both packages have the same file contents including the lib, the SONAME is `libmupdf.so.23.10`. Is there any special magic on *EL which I need to do for the provides? Differences I noticed in build.log: epel9 uses `cc` and has lto-wrapper: warning: using serial compilation of 47 LTRANS jobs fc39 uses `gcc` and has extra flags -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes Cheers Michael https://koji.fedoraproject.org/koji/taskinfo?taskID=113544172 https://koji.fedoraproject.org/koji/taskinfo?taskID=113544612 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
