> Are those really plugins then? "Plugins" usually aren't loaded by
> ld.so, but rather "dlopen"d.
> Unversioned .so files are usually not allowed to be in the ld.so paths.
> But if you put the ld.so config snippet into the subpackage that ships
> ld.so, but rather "dlopen"d.
> Unversioned .so files are usually not allowed to be in the ld.so paths.
> But if you put the ld.so config snippet into the subpackage that ships
> the runnable tests, that should be fine, I think ...
It contains all the necessary headers for the test subpackage mariadb-connector-c-test.
These headers re used only during testing and thus would be unnecessary clutter inside
libdir itself. I don't think dynamic linking is necessary in this situation because the only package
that interacts with the so file is the subpackage and the so file is only linked to its test files.
Sloboda Pavol.
On Tue, May 6, 2025 at 12:06 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
On Tue, May 6, 2025 at 11:55 AM Michal Schorm <mschorm@xxxxxxxxxx> wrote:
>
> > Is using %{_libdir}/x/y/z necessary? What are the reasons?
>
> In this particular case, it's the MariaDB stack.
>
> The 'libmariadb.so' is in the '%{_libdir}', but then there are some
> plugins, some restricted plugins, some test plugins,
> then the other packages from the stack use it too. We already have a
> few directories there.
> The path in question is a new one:
> %{_libdir}/mariadb/connector-c/tests/<some_lib>.so
> And the Pavol's question is targeted on using the ldconfig correctly
> so specifically the 'mariadb-connector-c-test' sub-package testsuite
> would work out for the box, for which it need the library to be found.
Are those really plugins then? "Plugins" usually aren't loaded by
ld.so, but rather "dlopen"d.
Unversioned .so files are usually not allowed to be in the ld.so paths.
But if you put the ld.so config snippet into the subpackage that ships
the runnable tests, that should be fine, I think ...
Fabio
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
