-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add lib path env when node_shared=true #18626
Conversation
Makefile
Outdated
@@ -239,6 +239,9 @@ v8: | |||
.PHONY: test | |||
# This does not run tests of third-party libraries inside deps. | |||
test: all ## Runs default tests, linters, and builds docs. | |||
ifeq ($(OSTYPE)$(NODE_TARGET_TYPE),darwinshared_library) | |||
$(MAKE) -s change-install-name | |||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be better to make change-install-name
a no-op itself, rather than making its usage conditional? The current implementation wouldn’t work on other OSes anyway, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's only for macOS. so you mean make it no-op for other platform?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yhwang Yes, exactly that 👍
Makefile
Outdated
# to the shared library with abs path. | ||
.PHONY: change-install-name | ||
change-install-name: | ||
install_name_tool -change /usr/local/lib/libnode.$(NODE_MODULE_VERSION).dylib \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is /usr/local/lib
hardcoded somewhere else, or should we use the actual prefix here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a good question. I don't know where it comes from. and that's important for shared lib embedders. If they build the shared lib, they may want to change it. And that's for macOS only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yhwang I guess it’s coming from $(PREFIX)
or ./configure --prefix=…
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see. if that's the case, let me change it to variable. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addaleax oops, seems the /usr/local/lib
comes from here: https://github.com/nodejs/node/blob/master/tools/gyp/pylib/gyp/xcode_emulation.py#L763
And it doesn't honor PREFIX
..... is this a bug?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Linux we use $ORIGIN
in rpath when linking. For macOS, we can use @loader_path
. Should I add a TODO in the comment and do the change in other PR?
In here, I will leave it to /usr/local/lib
for now. is that okay?
[Edit] There is @rpath
since macOS 10.5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addaleax I updated my change to use @rpath
. Then I reverted my change in Makefile
. You may take a look.
Makefile
Outdated
.PHONY: change-install-name | ||
change-install-name: | ||
install_name_tool -change /usr/local/lib/libnode.$(NODE_MODULE_VERSION).dylib \ | ||
$(shell pwd)/out/Release/libnode.$(NODE_MODULE_VERSION).dylib \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Release → BUILDTYPE
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Let me work on it.
test/common/index.js
Outdated
return; | ||
} | ||
process.env.LD_LIBRARY_PATH = | ||
path.join(path.dirname(process.execPath), 'lib.target'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this extend LD_LIBRARY_PATH
instead of replace it? (Same for LIBPATH
and DYLD_LIBRARY_PATH
below).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Let me change to extend these variables.
b354c8c
to
0295775
Compare
7318472
to
eed929e
Compare
failed on a flaky test case: |
test/common/index.js
Outdated
@@ -802,3 +802,32 @@ exports.hijackStdout = hijackStdWritable.bind(null, 'stdout'); | |||
exports.hijackStderr = hijackStdWritable.bind(null, 'stderr'); | |||
exports.restoreStdout = restoreWritable.bind(null, 'stdout'); | |||
exports.restoreStderr = restoreWritable.bind(null, 'stderr'); | |||
|
|||
// Check if the executable links to the shared lib node or not. | |||
exports.isSharedLibNode = process.config.variables.node_shared === true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is currently not used at all, right? If so, I would rather remove it again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure!
test/common/index.js
Outdated
process.env.PATH = | ||
(process.env.PATH ? process.env.PATH + path.delimiter : '') + | ||
path.dirname(process.execPath); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is only going to be called rarely, I feel like it would be better to move this to a separate file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move to a file which both test-child-process-fork-exec-path
and test-module-loading-globalpaths
can access? not familiar with the directory structure of the testing suites, any suggestion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is for example test/common/countdown.js
. Similar to that you can just add another file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BridgeAR I moved the function to a new file: shared-lib-util.js
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]>
eed929e
to
b6f1ae3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
May I have another CI to verify this PR again after I refactor the function to a separated js file? |
Only failed on pi1. However, on those 6 runs on pi1. 2 runs passed! (If I interpret the results correctly.) |
Landed in ec9e792 🎉 |
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: nodejs#18626 Refs: nodejs#18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: #18626 Refs: #18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: #18626 Refs: #18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: nodejs#18626 Refs: nodejs#18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
Should this be backported to edit: got it to land |
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: #18626 Refs: #18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
@MylesBorins thanks. |
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: #18626 Refs: #18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: #18626 Refs: #18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
When building the node with `--shared` option, the major output is the shared library. However, we still build a node executable which links to the shared lib. It's for testing purpose. When testing with the executable, some test cases move/copy the executable, change the relative path to the shared library and fail. Using lib path env would solve the issue. However, in macOS, need to change the install name for the shared library and use rpath in the executable. In AIX, `-brtl` linker option rebinds the symbols in the executable and addon modules could use them. Signed-off-by: Yihong Wang <[email protected]> PR-URL: #18626 Refs: #18535 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
When building the node with
--shared
option, the major output is theshared library. However, we still build a node executable which links
to the shared lib. It's for testing purpose. When testing with the
executable, some test cases move/copy the executable, change the relative
path to the shared library and fail. Using lib path env would solve the
issue. However, in macOS, need to modify the dependency in the
executable by using the install_name_tool utility. In AIX,
-brtl
linker option rebinds the symbols in the executable and addon modules
could use them.
Refs: #18535
Signed-off-by: Yihong Wang [email protected]
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test, build