Fix paths in dylib files using install_name_tool

Question

I'm trying to compile my C++ project after updating OS to El Capitan. However, I faced a few snags along the way:

dyld: Library not loaded: pathB/libIceUtil.34.dylib
Referenced from: pathA/libSlice.34.dylib
Reason: image not found

The problem is that pathB doesn't exist. When I run otool -L pathA/libIceUtil.34.dylib, I get

pathA/libIceUtil.34.dylib:
pathB/libIceUtil.34.dylib (compatibility version 0.0.0, current version 0.0.0)

install_name_tool -change pathB/libIceUtil.34.dylib pathA/libIceUtil.34.dylib pathA/libIceUtil.34.dylib didn't solve the problem. An article mentions using libtool. Any idea how I can fix this issue?

@trojanfoe `/Volumes/Data/builder/` prefix --> `/Users/xeroqu/lib/`prefix. I modified the question as well. — xeroqu, Oct 23 '15 at 07:28
@trojanfoe I tried that already - didn't fix. Updated the question again — xeroqu, Oct 23 '15 at 07:48
Having a similar problem that I think I've sorted. What did otool -L report when run on `libIceUtil.34.dylib`? In my case, the target library had moved but still thought it was in the old location, which seemed to cause problems. — sfjac, Nov 25 '15 at 02:28

trojanfoe · Accepted Answer · 2015-10-23T08:07:03.963

3

The first argument to install_name_tool -change is not correct (it doesn't match what otool -L printed). Use:

install_name_tool -change \
    /Volumes/Data/builder/Proj/gcc4/thirdparty/Ice-3.4.2-x86_64/lib/libIceUtil.34.dylib \
    /Users/xeroqu/lib/Proj/gcc4/thirdparty/Ice-3.4.2-x86_64/lib/libIceUtil.34.dylib \
    /Users/xeroqu/lib/Proj/gcc4/thirdparty/Ice-3.4.2-x86_64/lib/libIceUtil.34.dylib

edited Oct 23 '15 at 08:07

answered Oct 23 '15 at 07:52

trojanfoe

120,358
21
212
242

you're right and thus +1. However, I made a terrible mistake by copying, changing the project name and pasting it here - so the answer is not what I'm looking for. I simplified the question this time. Sorry for the hassle. – xeroqu Oct 23 '15 at 08:29
1

I don't know what else to suggest. I have successfully used `install_name_tool` to fix such issues in the past. There is a chance it relates to dependent libraries in the library itself... – trojanfoe Oct 23 '15 at 08:35
1

Funny thing is that it works w/o problems for executables, but not for dylibs. Thanks for the hints – xeroqu Oct 23 '15 at 08:38

Fix paths in dylib files using install_name_tool

1 Answers1