Shared library install_name

[laslett]

Thanks for the fabulous work on Magma, it's really great! I've a small bit of feedback. Not sure if this is generally relevant or peculiar to my install on Mac OS X.

When I link to Magma's shared library to make a standalone executable it's working great. However, when I'm creating a shared library of my own (linking to libmagma.so) which is loaded into various other software I sometimes (depending on the software I'm loading it into) encounter an error along the lines "Library not loaded: ./lib/libmagma.so" when my shared library is dlopen'ed. I installed it to /usr/local/lib so this is seems wrong. Indeed, when you examine the shared library you get a curious output:

Code: Select all

$ otool -L /usr/local/lib/libmagma.so
/usr/local/lib/libmagma.so:
	./lib/libmagma.so (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	@rpath/libcublas.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	@rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

That third line (./lib/libmagma.so) looks wrong. Why is the install name a relative path? I can manually change this using the install_name_tool command, but this feels like something that should be getting done in Magma's makefile surely?

Looking through the Magma makefile I don't see install_name_tool being called, nor is there a -install_name option after the -shared which is I guess the reason for this.

I can't claim to be an expert on these things, but I've checked all the other major libraries I use (e.g. GSL, GMP, FLINT, CUDA, ...) and they all have the full target path after install and they don't trigger the errors Magma does when used in exactly the same way. Can anyone who is an expert weigh in on whether this should be considered a bug to be fixed in Magma's make?

Thanks again for a great tool,

Louis

[mgates3]

I looked into the install_name a bit, and added these changes. This is not something I'm very familiar with, so please let me know if it doesn't look correct.

Code: Select all

===================================================================
--- Makefile	(revision 6252)
+++ Makefile	(working copy)
@@ -158,7 +158,7 @@
 
 $(LIBMAGMA_SO): src/*.o control/*.o interface_cuda/*.o magmablas/*.o
 	@echo ======================================== $(LIBMAGMA_SO)
-	$(CC) $(LDFLAGS) -shared -o $(LIBMAGMA_SO) $^ \
+	$(CC) $(LDFLAGS) $(INSTALL_NAME) -shared -o $(LIBMAGMA_SO) $^ \
 	$(LIBDIR) \
 	$(LIB)
 	@echo
mint ~/Documents/magma-trunk> svn diff make.inc.macos 
Index: make.inc.macos
===================================================================
--- make.inc.macos	(revision 6252)
+++ make.inc.macos	(working copy)
@@ -47,6 +47,9 @@
 NVCCFLAGS = -m64 -O3         -DADD_       -Xcompiler "-fno-strict-aliasing $(FPIC)"
 LDFLAGS   = -m64     $(FPIC)
 
+# MacOS likes the library's path to be set
+INSTALL_NAME = -install_name @rpath/libmagma.so

This seems to match what CUDA does (other than being called .so instead of .dylib):

Code: Select all

mint ~/Documents/magma-trunk> otool -L testing/testing_dgetrf
testing/testing_dgetrf:
	@rpath/libmagma.so (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	@rpath/libcublas.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	@rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version 6.0.37)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

-mark