Re: Rpm: provide a static library in package
On 2/22/22 19:47, Kevin Kofler via devel wrote: > Denis Fateyev wrote: >> The "ustl" upstream, for which I maintain the RPM package, has recently >> switched from providing a shared library to a static library. > > Generally, you do not want to follow such a change, but force the build > system to build a shared library instead, even if it is not the upstream > default. > > Kevin Kofler Would uSockets be an exception? That is designed to be used as a static library with link-time optimization, so that trivial functions (such as struct getters) can be inlined into users of the library. Not doing so is (according to their documentation) a huge performance hit. That said, should such a library just be shipped as source code? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rpm: provide a static library in package
On 23/02/2022 02:05, Denis Fateyev wrote: Unfortunately, the shared library support is explicitly removed by the upstream: You can revert this commit with a downstream patch. I believe it's not worth to work around this behavior additionally. From README: > This library is obsolete. Please use the official gcc C++ standard library. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rpm: provide a static library in package
On 22/02/2022 19:57, Denis Fateyev wrote: So I'm going to make changes in the package, and provide everything in "-devel" subpackage. No. You must patch the build manifest and force building as a shared library, regardless of the upstream choice. https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rpm: provide a static library in package
Denis Fateyev wrote: > Unfortunately, the shared library support is explicitly removed by the > upstream: > https://github.com/msharov/ustl/issues/100#issuecomment-1040553883 > https://github.com/msharov/ustl/commit/7366ab143d9bd0f48c59931c0c58529eb5179c27 This is just lame. I do not understand the explanation at all, since I do not see any scenario in which the static library makes things easier for the consumer of the library. I have added a commit comment saying so. And the fact that the library building code is handwritten is a WTF by itself. With any reasonable build system, changing a library from static to shared is at most a one-line change. But upstream's build system is not reasonable. > As an alternative, I can orphan the "ustl" package in rawhide — I haven't > checked yet, but suspect that it's not used by other packages nowadays. Well, if that is the case, considering that upstream themselves consider the library obsolete, I guess it is fine to orphan it and let it be retired eventually. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rpm: provide a static library in package
On Wed, Feb 23, 2022 at 6:47 AM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Denis Fateyev wrote: > > The "ustl" upstream, for which I maintain the RPM package, has recently > > switched from providing a shared library to a static library. > > Generally, you do not want to follow such a change, but force the build > system to build a shared library instead, even if it is not the upstream > default. > Unfortunately, the shared library support is explicitly removed by the upstream: https://github.com/msharov/ustl/issues/100#issuecomment-1040553883 https://github.com/msharov/ustl/commit/7366ab143d9bd0f48c59931c0c58529eb5179c27 I believe it's not worth to work around this behavior additionally. As an alternative, I can orphan the "ustl" package in rawhide — I haven't checked yet, but suspect that it's not used by other packages nowadays. -- wbr, Denis. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rpm: provide a static library in package
Denis Fateyev wrote: > The "ustl" upstream, for which I maintain the RPM package, has recently > switched from providing a shared library to a static library. Generally, you do not want to follow such a change, but force the build system to build a shared library instead, even if it is not the upstream default. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Rpm: provide a static library in package
Hello all,
The "ustl" upstream, for which I maintain the RPM package, has recently
switched from providing a shared library to a static library.
So I'm going to make changes in the package, and provide everything in
"-devel" subpackage.
I have looked through
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries
requirements — but there are some questions left.
1) Should I preserve debug information for the static library during build,
so the library can be stripped and debug packages can be created? Or, can I
just skip debug package creation with "%global debug_package %{nil}" ?
I know it's acceptable for header-only, but not sure for packages with
binary static libraries.
2) Can I use the stripping LDFLAGS option ("-s") right during the static
package build, not to strip anything after build? Or, let the built library
be stripped in terms of RPM package flow?
Thanks!
--
wbr, Denis.
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
