Can "ld" add the rpaths automatically to an executable if it can find the needed dylibs at link time?

The question is in the title, but anyway, let me explain it a bit more: The most accepted way for correctly defining the ***install name*** for a dylib in MacOS is by making it relative to the rpath. For example: otool -L ./LLVM/7.0.0/lib/libomp.dylib ./LLVM/7.0.0/lib/libomp.dylib: @rpath/libomp.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) Here, libomp.dylib has @rpath/libomp.dylib as its ***install name***. So far so good. The problem is when you create an executable linked to such a dylib. Even if you pass the correct -L/path/to/libomp.dylib flag at link time, so that ld can **successfully** link the executable, then you try to execute it, and obviously you get the following: dyld: Library not loaded: @rpath/libomp.dylib Referenced from: mydumbexecutable Reason: image not found Abort trap: 6 This of course can be fixed by using install_name_tool on either the dylib (changing its ***install name*** so that it doesn't depend on the rpath, and linking the executable again, but this is not considered good practice), or, the recommended way, to use install_name_tool on the executable, adding to it the proper rpath so that the dylib can be found. But... just wondering... isn't there a flag in ld that automatically adds the rpath for you? I mean, if ld is able to link the executable because it **did** find the dylibs, why cannot automatically store the proper rpath in the executable? I understand this should be optional behaviour, as sometimes you prefer to define the rpaths yourself, but... a flag for doing it automatically would make my life a lot easier.