Add install name for MacOS dylib

[Detegr]

I don't really know what is the state of the art way to handle this, but this feels better than leaving the dylib referencing an object from below the build directory.

Without setting the install name, the copied object will still reference to the original object, which is not going to work if it is ever moved out of CBQN directory:

$ otool -L libcbqn.dylib
libcbqn.dylib:
    build/obj2/linker-4qa8skka2dk9e991rjom3lns7elgmlak4h98e0bcb0t8os3o6o5/res (compatibility version 0.0.0, current version 0.0.0)

With this change the install name of the dylib object is set to libcbqn.dylib, so it can be moved around.

[dzaima]

This should definitely be better than whatever currently is happening, but from what I can tell by searching around a bit is that this might (?) result in it looking for libcbqn.dylib relative to the working directory, and to fix that you need like a @loader_path/libcbqn.dylib or @rpath/libcbqn.dylib (or I might be misreading things, idk; don't use macos, so can't test things). (but mostly i'm just confused as to why a library would even need to know its own path; that seems like a thing that the invoker should worry about, not cbqn. macos ¯\_(ツ)_/¯)

[Detegr]

You are right, good catch. I did some testing and seems to work like this:

libcbqn.dylib Only works when the executable is run from the same directory, i.e. running from the parent directory does not find the library anymore. @loader_path/libcbqn.dylib Only works when the dylib file is in the same directory as the executable linked against it. So system-wide installation would not be possible. @rpath/libcbqn.dylib Works the same way as .so files in Linux work. So you can either set rpath for the executable or use DYLD_LIBRARY_PATH environment variable to find the shared object.

So from these options I think @rpath/libcbqn.dylib makes the most sense, do you agree?

[dzaima]

I think rpath makes most sense, yeah