Hi, I have a recipe where I am getting a set of binaries files from a third party. These files are not well put together. For example they are linked to none versioned so-files for example
0x0000000000000001 (NEEDED) Shared library: [libnss3.so] 0x0000000000000001 (NEEDED) Shared library: [libnssutil3.so] 0x0000000000000001 (NEEDED) Shared library: [libnspr4.so] 0x0000000000000001 (NEEDED) Shared library: [libffmpeg.so] 0x0000000000000001 (NEEDED) Shared library: [libuuid.so] 0x0000000000000001 (NEEDED) Shared library: [libasound.so] 0x0000000000000001 (NEEDED) Shared library: [libmetrics.so] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libcutils.so] 0x0000000000000001 (NEEDED) Shared library: [libglibc_bridge.so] 0x0000000000000001 (NEEDED) Shared library: [libcurl.so] Some of these files are not supplied by the third party so for example libuuid.so is not supplied by them and this causes some friction when using rpm as the package. The dnf package manager will complain that nothing is supplying libuuid.so which is correct. I have tried to solve this by including libuuid.so.1 to the package and then create a link libuuid.so that points to the libuuid.so.1 library but dnf is not satisfied with that. I have made sure that the link is part of the package so it is not a mater of getting it included in the dev package. Renaming libuuid.so.1 to libuuid.so will not solve this problem because dnf checks the elf headers and detects that the SONAME is libuuid.so.1. I have considered using patchelf to modify the SONAME but at one point I get an error from the linker so I don't think it is the best approach. When looking at rpmbuild I can see that there is an option --no-deps so is there a way to supply these flags when creating the rpm package? Or supply some flags to dnf to prevent it from checking dependencies? Or are the only option to get the third party to supply something usable? BR Måns Zigher
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
