Note: this is also true for version 3.4-r1 During install phase, rspamd installs its libraries (or plugins) inside /usr/lib on 64 bits systems, due to an hardcoded path in cmake build files Reproducible: Always Steps to Reproduce: 1. ebuild mail-filter/rspamd-xxx install on a 64 bits system 2. Take a look at the end of the log (library stripping) 3. Take a look inside /usr/lib/rspamd and check that /usr/lib64/rspamd does not exists Actual Results: librspamd-<xxx>.so are distributed inside /usr/lib/rspamd Expected Results: librspamd-<xxx>.so should distributed inside /usr/lib64/rspamd A quite dirty (?) but simple sed command during the install phase: sed -e 's~/lib/~/'"$(get_libdir)"'/~' -i cmake/Paths.cmake || die Note that I always use '~' character as sed marker instead of more commonly used '/' because we often have to change pathes which usually contain '/'s
Created attachment 844295 [details] Output from emerge --info mail-filter/rspamd-3.3
Created attachment 844297 [details] Emerge log before patching the ebuild
Created attachment 844299 [details] Emerge log after patching the ebuild
Installing 64bit libs to /usr/lib/<package> is fine (some packages even do e.g. /usr/lib/<package>/lib64 + lib32), /usr/lib/libsomesomething.so wouldn't be fine because then it'd be in loader/linker search path.
What if you ever want to get multilib installation in that case ?
Why would you? Afaik it's private libraries/plugins in a private directory. Nothing needs to link against this, as such no need to provide multilib (and in most case multilib is avoided either way). Also, far from being the only package doing this, e.g. even python does: /usr/lib/python3.10/lib-dynload/mmap.cpython-310-x86_64-linux-gnu.so
This is true for this specific case. But, from my point of vue, as a software engineer used to work on embedded environments, every library, especially shared ones, should be candidate for multilib and cross-compiling. What would be the need of a shared library if it can not be shared ? After a cleanup on the machine I saw this, the only 64 bits libraries distributed inside /usr/lib are toolchains, python dynamic and rust ones, only a few ones are not using a specific marker (ie lib64 / x86_64-pc-linux-gnu subdir or x86_64 in their name) and I think the remaining ones can cause problems. Of course, this is just my point of vue...
I am going to change this in rspamd-3.4 only which I will stable request later.
OK, thank you.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a3f9e9a6627cc9c176498cee7226155633ba735d commit a3f9e9a6627cc9c176498cee7226155633ba735d Author: Petr Vaněk <arkamar@atlas.cz> AuthorDate: 2023-01-02 08:57:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-04 05:48:10 +0000 mail-filter/rspamd: respect libdir Closes: https://bugs.gentoo.org/887591 Signed-off-by: Petr Vaněk <arkamar@atlas.cz> Closes: https://github.com/gentoo/gentoo/pull/28933 Signed-off-by: Sam James <sam@gentoo.org> mail-filter/rspamd/{rspamd-3.4-r1.ebuild => rspamd-3.4-r2.ebuild} | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
