[CMake] Installation corrupts library on OS X

clinton at elemtech.com clinton at elemtech.com
Mon Oct 13 22:33:27 EDT 2014


----- Original Message -----

> Hi,

> I'm using CMake 3.0.2 on OS X 10.9.4. When I do a "make install", it's
> somehow corrupting some of my libraries at install time.

> Here is what otool reports for the library in my build directory - that is,
> the state of the library prior to installation:

> $ otool -L libOpenMMAmoebaCUDA.dylib
> libOpenMMAmoebaCUDA.dylib:
> /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoebaCUDA.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current
> version 6.0.37)
> /Users/peastman/workspace/openmm/bin-release/libOpenMM.dylib (compatibility
> version 0.0.0, current version 0.0.0)
> @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version
> 6.0.37)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> /Users/peastman/workspace/openmm/bin-release/libOpenMMCUDA.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoeba.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current
> version 6.0.37)
> @rpath/libcufft.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)

> No problems. Everything looks ok. Now here is what it reports for the same
> library in the install directory - the is, the state of the library after
> installation:

> $ otool -L /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib
> /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib:
> @rpath/libOpenMMAmoebaCUDA.dylib (compatibility version 0.0.0, current
> version 0.0.0)
> @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current
> version 6.0.37)
> @rpath/libOpenMM.dylib (compatibility version 0.0.0, current version 0.0.0)
> @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version
> 6.0.37)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> @rpath/libOpenMMCUDA.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> @rpath/libOpenMMAmoeba.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current
> version 6.0.37)
> @rpath/libcufft.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)
> load command 22 size zero (can't advance to other load commands)

> As expected, the absolute paths have been replaced by relative paths. But it
> also now reports an error message at the end about "load command 22 size
> zero". This error does not prevent the library from actually being loaded.
> It seems to work fine as far as that is concerned. However, if I try to use
> install_name_tool to make any further changes to the paths in the library it
> fails with an error message:

> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> for architecture i386 object:
> /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib malformed object
> (load command 22 cmdsize is zero)

> Any idea what's going on?

Yeah, I think you have duplicate LC_RPATH load commands. In that case, your binaries can be corrupted by install_name_tool during "make install." 
To check if that is your case, you can run this on the binary before installation to see if you have duplicates. 

otool -l app | grep -A2 LC_RPATH 

If the duplicates come from your own linker flags such as, -Wl,-rpath,/some/path, you may need to remove those. 
Otherwise, it would help if you can provide a minimal test case to reproduce the problem. 

It would also help if someone could report this corruption by install_name_tool bug to Apple. You are the second to come to this mailing list about this bug. 

Clint 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141013/1708db4d/attachment-0001.html>


More information about the CMake mailing list