Failed to run tests while building tarantool from source on mac os #5959
Assignees
Milestone
Comments
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Apr 5, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
that referenced
this issue
Apr 5, 2021
LuaJIT submodule is bumped to introduce the following changes: * test: fix dynamic modules loading on MacOS * test: make utils.selfrun usage easier * test: remove excess dependency for tests target Within this changeset SIP issues are worked around and dynamic modules loading on MacOS is fixed. As a result LuaJIT tests can be enabled for static build target on MacOS. Closes #5959 Follows up #4862 Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Apr 6, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Apr 7, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
that referenced
this issue
Apr 7, 2021
LuaJIT submodule is bumped to introduce the following changes: * test: fix dynamic modules loading on MacOS * test: make utils.selfrun usage easier * test: remove excess dependency for tests target Within this changeset SIP issues are worked around and dynamic modules loading on MacOS is fixed. As a result LuaJIT tests can be enabled for static build target on MacOS. Closes #5959 Follows up #4862 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Apr 7, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit fae1681)
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Apr 7, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit fae1681)
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Apr 7, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit fae1681)
igormunkin
added a commit
that referenced
this issue
Apr 7, 2021
LuaJIT submodule is bumped to introduce the following changes: * test: fix dynamic modules loading on MacOS * test: make utils.selfrun usage easier * test: remove excess dependency for tests target Within this changeset SIP issues are worked around and dynamic modules loading on MacOS is fixed. As a result LuaJIT tests can be enabled for static build target on MacOS. Closes #5959 Follows up #4862 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 0c4d52a)
igormunkin
added a commit
that referenced
this issue
Apr 7, 2021
LuaJIT submodule is bumped to introduce the following changes: * test: fix dynamic modules loading on MacOS * test: make utils.selfrun usage easier * test: remove excess dependency for tests target Within this changeset SIP issues are worked around and dynamic modules loading on MacOS is fixed. As a result LuaJIT tests can be enabled for static build target on MacOS. Closes #5959 Follows up #4862 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 0c4d52a)
igormunkin
added a commit
that referenced
this issue
Apr 7, 2021
LuaJIT submodule is bumped to introduce the following changes: * test: fix dynamic modules loading on MacOS * test: make utils.selfrun usage easier * test: remove excess dependency for tests target Within this changeset SIP issues are worked around and dynamic modules loading on MacOS is fixed. As a result LuaJIT tests can be enabled for static build target on MacOS. Closes #5959 Follows up #4862 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
|
The issue is resolved in scope of tarantool/luajit@fae1681. The submodule was updated in tarantool in 2.8.0-204-g0c4d52a23 (0c4d52a), 2.7.1-187-g9719804b9 (9719804), 2.6.2-182-g82573a913 (82573a9), 1.10.9-114-g96e0397e7 (96e0397). |
Shishqa
pushed a commit
to Shishqa/luajit
that referenced
this issue
May 8, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Shishqa
pushed a commit
to Shishqa/luajit
that referenced
this issue
May 9, 2021
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Jun 16, 2022
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Jun 16, 2022
This patch resolves the issue with running the tests with auxiliary dynamically loaded modules in case of out-of-source build. The first issue relates to the way modules to be loaded at runtime are built on MacOS. Since the auxiliary libraries are built as a dynamically loaded modules on MacOS instead of shared libraries as it is done on Linux and BSD, another environment variable should be used to guide <ffi.load> while searching the extension. Hence the values collected in scope of <BuildTestCLib> macro need to be set to DYLD_LIBRARY_PATH variable instead of LD_LIBRARY_PATH on MacOS. Unfortunately, this rather small change doesn't resolve the problem at all and the root cause lies much deeper than it seems at the beginning. Apple tries their best to "protect their users from malicious software". As a result SIP[1] has been designed and released. Now, Apple developers are *so protected*, that they can load nothing being not installed in the system, since some programs sanitize the environment before they start child processes. Specifically, environment variables starting with DYLD_ and LD_ are unset for child process started by system programs[2]. That which does not kill us makes us stronger: fortunately, these environment variables are used by FFI machinery to find the proper shared library, hence we can still tweak testing environment before calling <ffi.load>. However, the value can't be passed via the standard environment variable, so we prepend TEST_ prefix to its name to get around SIP magic tricks. Finally, to set the variable required by FFI machinery the introduced <utils.tweakenv> routine is used. PROFIT! Your move, Cupertino geniuses. [1]: https://support.apple.com/en-us/HT204899 [2]: https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html Resolves tarantool/tarantool#5959 Follows up tarantool/tarantool#4862 Co-authored-by: Sergey Ostanevich <sergos@tarantool.org> Co-authored-by: Mons Anderson <mons@cpan.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
I tried to build Tarantool from source on MacOS and failed on running tests.
Steps to reproduce
I followed this instruction:
MAKE TEST OUTPUT
The text was updated successfully, but these errors were encountered: