[make] Set rpath for hdll builds #571
Conversation
Makefile
Outdated
| @@ -107,6 +108,7 @@ else | |||
| # Linux | |||
| CFLAGS += -m$(MARCH) -fPIC -pthread -fno-omit-frame-pointer | |||
| LFLAGS += -lm -Wl,-rpath,.:'$$ORIGIN':$(INSTALL_LIB_DIR) -Wl,--export-dynamic -Wl,--no-undefined | |||
| HDLLFLAGS += -Wl,-rpath,$(INSTALL_LIB_DIR) | |||
There was a problem hiding this comment.
It should be noted that if HashLink is meant to be shipped as part of a game (as in Shiro games), then the HDLLs should have an rpath that is something like @executable_path/foo.hdll (depends on the concrete directory structure of course). So the HDLLs will need to be patched with install_name_tool.
There was a problem hiding this comment.
These changes only affect Linux, right now we don't do anything rpath related on mac.
There was a problem hiding this comment.
These rpath issues have been a pain for a while. Maybe I'll open a separate issue so that we can discuss resolving them properly for all use cases.
There was a problem hiding this comment.
For now, I've added ORIGIN to the hdll's rpath so that it can load libhl from the same directory as well. This should cover the case where all the binaries are packaged in a single folder.
then the HDLLs should have an rpath that is something like @executable_path/foo.hdll
Also note, this is about how the loader resolves libhl as a dependency of a hdll, not the other way around.
This way, libhl.so can be in the same folder as the hdll
Technically this shouldn't have been an issue anyway, but homebrew does a check to make sure all binaries that are linked to dynamic libraries can definitely load their linked libraries. Since no rpath was set for the hdlls, they were causing these tests to fail.
Homebrew/homebrew-core#99237