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.
The answer to your question is: no, it cannot.

Your question sounds a lot like an XY problem, so first I would recommend going back and reexamine if this really is your main problem, or there's some higher level problem that is actually the problem, you're trying to solve.

First off, I would note that you do not have to use install_name_tool to set these values after the fact. You can set these while compiling the library and the program. If you're using clang/gcc, you can use the -install_name option. Similar exists for other compilers.

The reason that ld doesn't automatically add rpaths according to where it found the dylibs is that this would in general produce a binary that runs on your machine, and your machine only. I.e. it is tailored for your specific installation. This is normally not what you want. You want to produce a binary that others can take and run on their computers.

If you're making a "standard project" (i.e. like from an Xcode template) with shared libraries, you won't have to fiddle with rpaths or install names. I.e. usually you have the shared libraries placed at standard locations that are search by the dynamic linker by standard, so that you won't have to define anything special.

However, it seems you're wanting to create something very customized for your usage. If you really want to specify that the dylib is at a specific place (because you only want to run it on your own computer, or computers set up like yours) - you can do so by simply specifying an absolute path for it.

If you want to create something that can easily be copied to other computers without needing seperate installation of dylibs, you often want to bundle your dylib with the application itself. Then you can use a path relative to the executable by using @executable_path instead of @rpath. 

In my view @rpath is most helpful when you have multiple applications that are "loosely connected" that you would like to share a library that you do not want to place in a system-wide standard location.