Mac chimera app uses build libatomstruct.dylib instead of installed version

[Tom Goddard]

The Mac Chimera app is using build versions of the shared libraries (like libatomstruct.dylib) instead of the versions installed in the app (in Chimera.app/Contents/lib). Apparently the rpath library linkage is not working. This caused difficult to debug crashes -- spent the last hour debugging this.

The Mac crash dumps I was getting happened because the installed app _mmcif.so was using the build version of libatomstruct.dylib instead of the installed version of that library. The attached Mac crash log appears to indicate that the linker searched the entire /Users/goddard tree to find libatomstruct.dylib while for libmolc.dylib it looked in Chimera2.app/Contents/lib

0x102f5f000 - 0x102f71fff +libmolc.dylib (0) <FF8C313E-5ABA-3157-95D4-78540289774F> /Users/USER/*/Chimera2.app/Contents/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/chimera/core/atomic/libmolc.dylib
0x102f7e000 - 0x102fd7fff +libatomstruct.dylib (0) <13301820-1D66-34C8-A242-3F6D1BD347C4> /Users/USER/*/libatomstruct.dylib
0x102ff5000 - 0x102ff7ff7 +libelement.dylib (0) <604EB714-7719-3CF6-A19F-DF8C1C21E3B6> /Users/USER/*/libelement.dylib
0x102ffa000 - 0x103050fff +libtmpl.dylib (0) <563BAD62-E933-3699-A115-20C2CEE7EFE7> /Users/USER/*/libtmpl.dylib

[Greg Couch]

We should be removing all of the build directory information out of the .dylib and .so files. So that should not be possible. So the id's of all of the dylibs should be @rpath/*.dylib, and all the references to those files should be fixed too (not needed if the file already has its id changed before the linking takes place).

Scanning today's daily build, I see that LeapPython.so has a reference to /Users/goddard/ucsf/chimera2/build/Library/Frameworks/Python.framework/Versions/3.4/Python, so that must be incorrectly hardcoded. There are also references to /opt/local/Libraries-x64/boost_1_55_0/lib in libLeap.dylib.

In ChimeraX_Daily.app/Contents/lib/python3.5/lib, PIL and matplotlib have thier own .dylibs directory with "duplicated" shared libraries. That needs investigating. This doesn't appear on Linux.

Finally, ChimeraX_Daily.app/Contents/lib/python3.5/config-3.5m/libpython3.5.dylib has a reference to /private/var/tmp/chimerax_build/develop/chimerax/build/Library/Frameworks/Python.framework/Versions/3.5/Python and its RPATH set to /private/var/tmp/chimerax_build/develop/chimerax/build/lib. Both of those need to be fixed. And that incorrect RPATH shows up in many .so files.

The above is most likely the source of the problem.

[Tom Goddard]

The crash log indicates libraries like /Users/USER/*/libatomstruct.dylib which suggest it searched my entire home directory.

I just tested if I remove the installed libatomstruct.dylib then the ChimeraX on my machine still starts and opens molecules. But with a daily build if I remove that library it does not start. So it does not seem to be searching my home directory. Still we need to eliminate the dependencies to the build libraries or it becomes difficult to debug the installed version in cases where the build and install libraries are different.

[Greg Couch]

Found that -Wl,-rpath,@exec... argument to Python configure caused path to appear in shared libraries as well as the executable. That is now gone and scan-darwin.py script doesn't find any problems in ChimeraX.app.