Is it intentional that the libraries are not installed into %{_libdir}, i.e. /usr/lib64 on 64-bit systems? Same for the CMake files. One way to fix this is to add include(GNUInstallDirs), then use CMAKE_INSTALL_LIBDIR. Another is to use lib%{LLVM_LIBDIR_SUFFIX}.

But I'm not sure if this works, the application might look for the libraries in the wrong path.

Eyad Issa (VaiTon) - 9 days ago

author source maintainer target maintainer

I tried moving them with a raw and dirty mv, but then it wasn't working because it was searching in the wrong paths.

I tried a lot of options for cmake to set it to use lib64, but with no luck. GNUInstallDirs should be already included upstream: https://github.com/AdaptiveCpp/AdaptiveCpp/blob/15647ad4a0aaf411f8b53385625bb4cef598e71c/CMakeLists.txt#L634

---

Aaron Puchert (aaronpuchert) - 1 day ago

target maintainer

Ok, I thought this would happen. Maybe you can open a discussion with upstream to support changing the path. They can get the distribution default from CMake, as mentioned, and then use it in the source where the lookup happens using configure_file or add_compile_definitions.

Also can you make sure that builds are either successful, excluded, or unresolvable? There are lots of failing builds currently. Either add ExcludeArch or ExclusiveArch, or make sure it builds on the other architectures.

For Leap, it seems you're using /usr/etc, which is not used there yet. If you want to keep the files there, add it as %dir on Leap. See https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto.

The libraries in hipSYCL also look like plugins to me and should probably be build as MODULE. Only libacpp-common.so and libacpp-rt.so look like proper SHARED libraries, guessing from the Requires on the main package.

Eyad Issa (VaiTon) - 9 days ago

author source maintainer target maintainer

I also get it by rpmlint now: [ 113s] libadaptivecpp.x86_64: W: no-soname /usr/lib/libacpp-clang.so [ 113s] The library has no soname.

I'm trying to patch the other ones now

---

Eyad Issa (VaiTon) - 9 days ago

author source maintainer target maintainer

Update: setting libllvm-to-backend.so as MODULE gives me

[    8s] CMake Error at src/runtime/CMakeLists.txt:305 (target_link_libraries):
[    8s]   Target "llvm-to-host" of type MODULE_LIBRARY may not be linked into another
[    8s]   target.  One may link only to INTERFACE, OBJECT, STATIC or SHARED
[    8s]   libraries, or to executables with the ENABLE_EXPORTS property set.

---

Aaron Puchert (aaronpuchert) - 1 day ago

target maintainer

You're right, I must have overlooked the detected dependency. Maybe I forgot to check the dependencies of libadaptivecpp. There we have additionally libllvm-to-backend.so()(64bit) and libllvm-to-host.so()(64bit)

---

Aaron Puchert (aaronpuchert) - 1 day ago

target maintainer

Not necessarily wrong. Plugins shouldn't have an SO name, at the same time libraries in %{_libdir} usually have one. Some applications have subdirectories for plugins, maybe this could be an option here as well. But discuss this with upstream first.