From <ka...@redhat.com>: ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/300394 Change subject: cmake: find libhandle.so on Debian 9 and Ubuntu 16.04, 16.10 — again ...................................................................... cmake: find libhandle.so on Debian 9 and Ubuntu 16.04, 16.10 — again tl;dnr: previous fix wasn't quite right, cmake's check_library_exists macro is byzantine ~ as in complex — and poorly documented. This hack seems to work. The gory details: In the newest Debian and Ubuntu releases the developers (xfsprogs and/or Debian) have rather strangely chosen to put the libhandle.so.* shared libs in /lib instead of the more common /usr/lib or /usr/lib/x86_64-linux-gnu directories. In the same vein the xfslibs-dev package also installs the libhandle.so symlink in /lib. Unfortunately though, cmake's check_library_exists macro doesn't check /lib, or it checks /usr/lib first, where it finds libhandle.a. Since the code in libhandle.sa isn't compiled with -PIC, it won't link with another shared lib. (On other architectures, e.g. ARM, it will work because all code is always compiled with -PIC.) Getting into tl;dnr territory, cmake may think check_library_exists worked, but then later the build will fail because of the PIC/non-PIC mismatch. Through trial-and-error we see the following behavior of check_library_exists: a) check_library_exists(handle "open_by_handle" "" HAVE_XFS_LIB) Link with /usr/lib/libhandle.a, cmake test fails[1], XFS is disabled in config, packaging fails for missing libfsalxfs.so. b) check_library_exists(handle "open_by_handle" "lib" HAVE_XFS_LIB) Link with -L/home/kkeithle/src/nfs-ganesha-2.4.1/src/CMakeFiles/CMakeTmp/lib but actually links with /usr/lib/libhandle.a, cmake test fails, etc. c) check_library_exists(handle "open_by_handle" "/lib" HAVE_XFS_LIB) Linked as with a) above. cmake test fails, etc. d) check_library_exists(handle "open_by_handle" "/bunny/foo/foo" HAVE_XFS_LIB) (seems a silly test, yes, but instructive). Links with ...-L/bunny/foo/foo -lhandle -Wl,-rpath,/bunny/foo/foo... e) check_library_exists(handle "open_by_handle" "/./lib" HAVE_XFS_LIB) Links with ...-L/./lib -rdynamic -lhandle -Wl,-rpath,/./lib..., the test reports success, xfs is enabled in the build, and the build and packaging are successful. So, it's a conundrum as to why "/lib" doesn't do the right thing. cmake's check_library_exists seems to treat "/lib" as special somehow, although I can't untangle the macro definition to see where that's happening, or why. In any event "/./lib" appears to work and I've already spent way more time on this than it deserves. Change-Id: I72b0e37d84ef9be6a65e6c74c711f4de64bef322 Signed-off-by: Kaleb S. KEITHLEY <kkeit...@redhat.com> --- M src/CMakeLists.txt 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/94/300394/1 -- To view, visit https://review.gerrithub.io/300394 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I72b0e37d84ef9be6a65e6c74c711f4de64bef322 Gerrit-PatchSet: 1 Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Owner: ka...@redhat.com ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
