orion icon indicating copy to clipboard operation
orion copied to clipboard

add roothide support

Open roothider opened this issue 1 year ago • 8 comments

What does this implement/fix? Explain your changes.

add roothide support

Does this close any currently open issues?

no

Any relevant logs, error output, etc?

Any other comments?

no

Where has this been tested?

Operating System: macos

Platform: arm64

Target Platform: ios15/16/17

Toolchain Version: clang-1400.0.29.202

SDK Version: 15.4

roothider avatar Sep 02 '24 18:09 roothider

This questions spawns from my ignorance of Xcode -- is there a reason the search path list isn't just:

LD_RUNPATH_SEARCH_PATHS = (
	"$(inherited)",
	"@executable_path/Frameworks",
	"@loader_path/Frameworks",
	"@rpath/Library/Frameworks",
);

considering that @loader_path/.jbroot is a valid rpath?

L1ghtmann avatar Nov 23 '24 20:11 L1ghtmann

This questions spawns from my ignorance of Xcode -- is there a reason the search path list isn't just:


LD_RUNPATH_SEARCH_PATHS = (

	"$(inherited)",

	"@executable_path/Frameworks",

	"@loader_path/Frameworks",

	"@rpath/Library/Frameworks",

);

considering that @loader_path/.jbroot is a valid rpath?

yes @loader_path/.jbroot is a valid rpath on rh. ❤️

roothider avatar Nov 24 '24 08:11 roothider

Tuan and I discussed this briefly and wonder if it may be worthwhile to pass the rootless rpath flags to Xcode as well (see https://github.com/theos/theos/blob/master/vendor/mod/rootless/instance/rules.mk) which would allow, among other things, us to use @rpath here and simplify the search path list.

L1ghtmann avatar Dec 08 '24 00:12 L1ghtmann

Have you tested this? This doesn't seem valid to me, as the rpath would be recursive if I'm understanding correctly

leptos-null avatar Dec 08 '24 06:12 leptos-null

It looks to me (via testing) that dyld does detect the cycle, and stops.

num.c:

int someFunc(void) {
    return 2;
}

numctl.c:

extern int someFunc(void);

int main(void) {
    return someFunc();
}

test:

clang '-Wl,-dylib,-install_name,@rpath/libnum.dylib' num.c -o libnum.dylib
clang numctl.c -lnum -L. -o numctl -rpath '@rpath/.'
./numctl
# dyld[79285]: Library not loaded: @rpath/libnum.dylib
#   Referenced from: ./numctl
#   Reason: tried: '@rpath/./libnum.dylib' (no such file), '@rpath/./libnum.dylib' (no such file)
uname -v
# Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000

Another test that more closely matches what I understand as the use-case here.

clang '-Wl,-dylib,-install_name,@rpath/libaux.dylib' aux.c -o extra/libaux.dylib
clang '-Wl,-dylib,-install_name,@rpath/libnum.dylib' -rpath '@rpath/extra' -laux -Lextra num.c -o libnum.dylib
clang -rpath '@executable_path' -lnum -L. numctl.c -o numctl
./numctl
dyld[80465]: Library not loaded: @rpath/libaux.dylib
  Referenced from: /private/tmp/link-test/libnum.dylib
  Reason: tried: '@rpath/extra/libaux.dylib' (no such file), '/private/tmp/link-test/libaux.dylib' (no such file), '/private/tmp/link-test/libaux.dylib' (no such file)

Based on this, I do not believe using @rpath in the runtime paths definition will expand as expected.

leptos-null avatar Dec 08 '24 07:12 leptos-null

It looks to me (via testing) that dyld does detect the cycle, and stops.

num.c:

int someFunc(void) {
    return 2;
}

numctl.c:

extern int someFunc(void);

int main(void) {
    return someFunc();
}

test:

clang '-Wl,-dylib,-install_name,@rpath/libnum.dylib' num.c -o libnum.dylib
clang numctl.c -lnum -L. -o numctl -rpath '@rpath/.'
./numctl
# dyld[79285]: Library not loaded: @rpath/libnum.dylib
#   Referenced from: ./numctl
#   Reason: tried: '@rpath/./libnum.dylib' (no such file), '@rpath/./libnum.dylib' (no such file)
uname -v
# Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000

Another test that more closely matches what I understand as the use-case here.

clang '-Wl,-dylib,-install_name,@rpath/libaux.dylib' aux.c -o extra/libaux.dylib
clang '-Wl,-dylib,-install_name,@rpath/libnum.dylib' -rpath '@rpath/extra' -laux -Lextra num.c -o libnum.dylib
clang -rpath '@executable_path' -lnum -L. numctl.c -o numctl
./numctl
dyld[80465]: Library not loaded: @rpath/libaux.dylib
  Referenced from: /private/tmp/link-test/libnum.dylib
  Reason: tried: '@rpath/extra/libaux.dylib' (no such file), '/private/tmp/link-test/libaux.dylib' (no such file), '/private/tmp/link-test/libaux.dylib' (no such file)

Based on this, I do not believe using @rpath in the runtime paths definition will expand as expected.

dyld has never supported @rpath in rpath, dyld only supports @loader_path/@executable_path in rpath: https://github.com/apple-oss-distributions/dyld/blob/66c652a1f1f6b7b5266b8bbfd51cb0965d67cc44/dyld/Loader.cpp#L1301C1-L1305C1

roothider avatar Dec 09 '24 15:12 roothider

@leptos-null

roothider avatar Jan 09 '25 13:01 roothider

Thanks for confirming @roothider 👍

This PR looks good to me in terms of the change working. I'm not sure if we've started integrating roothide paths into other Theos components. Personally, I'm fine with adding this path here.

leptos-null avatar Jan 24 '25 04:01 leptos-null