oneDNN: compat_libs does not look correct when building shared lib

It’s may or may not be oneDNN’s problem. I’m looking into it. 🤔️

If libdnnl.so is built in a non-standard path, that libmkldnn.so could point to non-existing dependency (by default, it just points to ./libdnnl.so that is located somewhere else). In turn this makes the install fail, as copying the invalid symlink leads to cp failure (unless -P option is passed, that cmake doesn’t do).

@pinzhenx, is this the behavior you observe? If so, could you please check the following patch for Linux?

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 5a16687c1..6aecb68b2 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -182,7 +182,11 @@ else()
             COMMAND ${CMAKE_COMMAND} -E create_symlink libdnnl${ext_and_ver} ${compat_link}
             DEPENDS ${LIB_NAME})
         add_custom_target(compat_libs${ver} ALL DEPENDS ${compat_link})
-        install(FILES ${compat_link} DESTINATION ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR})
+        set(install_compat_link "${compat_link}")
+        if(NOT IS_ABSOLUTE "${install_compat_link}")
+            set(install_compat_link "${CMAKE_CURRENT_BINARY_DIR}/${install_compat_link}")
+        endif()
+        install(FILES ${install_compat_link} DESTINATION ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR})
     endforeach()
 endif()

The Windows part of this issue is resolved by #806. Do we still need to figure out what’s happening on Linux?

Still having a standalone reproducer would be nice to have. Otherwise it is unclear whom to blame 😃 Maybe this is due to the way oneDNN is integrated to pyTorch.