Xilinx / libdfx

Other
5 stars 3 forks source link

No SONAME/SOVERSION defined #2

Open lool opened 2 years ago

lool commented 2 years ago

Hi!

libdfx.so currently has no SONAME/SOVERSION defined, which breaks a number of things when creating distro packages (e.g. Ubuntu packages in my case). For instance, when trying to compute shared library dependencies from dfx-mgr on libdfx, dpkg-shlibdeps wont be able to extract the name of the library from libdfx.so, and the dfx-mgr binary won't properly have a libdfx "NEEDED" dependency on the lib.

Typically, libraries shipped in linux distros will:

For now, while creating packaging aimed at Ubuntu, I've worked around this by defining an Ubuntu specific SONAME "0ubuntu1" with this change:

--- libdfx-2021.2.orig/src/CMakeLists.txt
+++ libdfx-2021.2/src/CMakeLists.txt
@@ -19,6 +19,8 @@ set(LIBDFX_INCLUDE_DIRS
 )

 add_library(dfx ${libdfx_sources})
-set_target_properties(dfx PROPERTIES PUBLIC_HEADER "include/libdfx.h")
+set_target_properties(dfx PROPERTIES
+   VERSION 0ubuntu1
+   PUBLIC_HEADER "include/libdfx.h")
 target_include_directories(dfx PUBLIC ${LIBDFX_INCLUDE_DIRS})
 install(TARGETS dfx ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} PUBLIC_HEADER ${CMAKE_INSTALL_INCLUDEDIR})

So now, the packaged library properly appears with a "SONAME" property (objdump -x libdfx.so | grep SONAME) of libdfx.0ubuntu1, and I also get a libdfx.so symlink that I can ship in the libdfx-dev package.

Obviously, having to track ABI/API downstream in the Ubuntu packaging is cumbersome as it creates Ubuntu specific binaries, extra work and a risk of errors, so it'd be awesome if you could document API/ABI guarantees and define a SONAME in your releases so that all projects downstream of libdfx use the same SONAME. :-)

Thanks!

lool commented 2 years ago

Perhaps also worth considering installing libdfx.h under libdfx/, so that you can more easily expand/rev/branch your API.