[petsc-users] soname seems to be absent in OS-X

[Denis Davydov]

Hi Barry,

I think you use it already. After configure /lib/petsc/conf/petscvariables :

SL_LINKER_FUNCTION = -dynamiclib -install_name $(call SONAME_FUNCTION,$(1),$(2)) -compatibility_version $(2) -current_version $(3) -single_module -multiply_defined suppress -undefined dynamic_lookup
SONAME_FUNCTION = $(1).$(2).dylib

on the linking stage in the homebrew logs I see that the exact linking line contains -install_name :

-Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -O -dynamiclib -install_name /private/tmp/petsc20151027-97392-7khduu/petsc-3.6.2/real/lib/libpetsc.3.6.dylib -compatibility_version 3.6 -current_version 3.6.2 -single_module -multiply_defined suppress -undefined dynamic_lookup


If I do configure manually (bare-bones PETSc) and compile it, the install_name seems to be correct (note that it’s libpetsc.3.6.dylib instead of libpetsc.3.6.2.dylib) :
—————
$ otool -D arch-darwin-c-debug/lib/libpetsc.3.6.2.dylib
arch-darwin-c-debug/lib/libpetsc.3.6.2.dylib:
/Users/davydden/Downloads/petsc-3.6.2/arch-darwin-c-debug/lib/libpetsc.3.6.dylib

executable linked against end up using correct ABI version:
$ otool -L test | grep petsc
	/Users/davydden/Downloads/petsc-3.6.2/arch-darwin-c-debug/lib/libpetsc.3.6.dylib (compatibility version 3.6.0, current version 3.6.2)
—————


however after installation to —prefix=/Users/davydden/Downloads/petsc-3.6.2/real the install name ends up being wrong:
—————
$ otool -D real/lib/libpetsc.3.6.2.dylib
real/lib/libpetsc.3.6.2.dylib:
/Users/davydden/Downloads/petsc-3.6.2/real/lib/libpetsc.3.6.2.dylib

executable linked against end up using libpetsc.3.6.2.dylib instead of ABI version:
otool -L test | grep petsc
	/Users/davydden/Downloads/petsc-3.6.2/real/lib/libpetsc.3.6.2.dylib (compatibility version 3.6.0, current version 3.6.2)
—————

My guess would be there is something wrong happening in `make install`.
Perhaps when using “install_name_tool” with "-id” flag to change a library’s install name.
As a workaround i will fix install name manually, but you may consider investigating this issue further.


p.s. an excerpt from http://cocoadev.com/ApplicationLinking :

Unlike many OSes, OS X does not have a search path for the dynamic linker**. This means that you can't simply put a dynamic library in some "standard" location and have dyld find it, because there is no standard location. Instead, OS X embeds an "install name" inside each dynamic library. This install name is the path to where the library can be found when dyld needs to load it. When you build an application that links against a dynamic library, this install name is copied into the application binary. When the application runs, the copied install name is then used to locate the library or framework.

** Technically, dyld does have a search path, defined in the DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH variables. However, these are empty on OS X by default, so they rarely matter.

Kind regards,
Denis 

> On 29 Oct 2015, at 22:01, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> 
>  Denis,
> 
>   We don't understand what purpose a soname serves on Apple or how to add it. If you need it let us know how to install PETSc so that it is set and we will do it.
> 
>   Barry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20151101/3d586cbf/attachment.html>