-
Notifications
You must be signed in to change notification settings - Fork 78
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
LC_RPATH not added when compiling XS modules on macOS #402
Comments
This change fixes issue Perl-Toolchain-Gang#402 on my machine.
Added a PR that seems to fix this issue, see #403 . |
This fixes issue Perl-Toolchain-Gang#402 This change fixes issue Perl-Toolchain-Gang#402 on my machine.
Added a new test case that tests a special case for the generation of XS modules on OS darwin. More specifically, it tests if we are able to compile an XS module which refers to another shared library in a non-standard location such that we can load the XS module from a perl script without having to set the DYLD_LIBRARY_PATH environment variable. See PR Perl-Toolchain-Gang#403 and issue Perl-Toolchain-Gang#402.
Was really hoping this patch would let me compile DBD::Firebird against Firebird.framework, but it didn't change it. :(
I have not been able to get it to find the Firebird framework. I even disabled SIP and reinstalled the Xcode command-line tools. No joy. Is this a different issue? |
Yeah, pretty weird, right? |
It seems like the
|
Oh weird. I wonder what it should be pointing at? (I uninstalled and got things working in a docker container to solve my problem.) |
@theory Added bug report and a possible fix, see mariuz/perl-dbd-firebird#52. Could you test the PR as I am not able to test it myself since I am using Apple M1 chip? |
Added a new test case that tests a special case for the generation of XS modules on OS darwin. More specifically, it tests if we are able to compile an XS module which refers to another shared library in a non-standard location such that we can load the XS module from a perl script without having to set the DYLD_LIBRARY_PATH environment variable. See PR #403 and issue #402.
This fixes issue Perl-Toolchain-Gang#402 This change fixes issue Perl-Toolchain-Gang#402 on my machine.
Added a new test case that tests a special case for the generation of XS modules on OS darwin. More specifically, it tests if we are able to compile an XS module which refers to another shared library in a non-standard location such that we can load the XS module from a perl script without having to set the DYLD_LIBRARY_PATH environment variable. See PR Perl-Toolchain-Gang#403 and issue Perl-Toolchain-Gang#402.
Further light on this issue might be shed by @kiwiroy's findings on PDLPorters/pdl#391, fixing a problem of those linking to Alien::proj's provided I gather Roy will also investigate whether the |
Create a GitHub workflow to test CommonMark against all supported versions of Perl and cmark on Linux, macOS, and Windows. Include tests for the system default Perl and and package-supplied cmark on Linux (Apt) and macOS (Homewbrew), as well. Each version of cmark has two steps: one for macOS and Linux using `build.sh`, and one for Windows using `build.ps1`. Just add new steps to test new versions. Perls: 5.38, 5.36, 5.34, 5.32, 5.30, 5.28, 5.26, 5.24, 5.22, 5.20, 5.18, 5.16, 5.14, 5.12, 5.10, 5.8, macOS system, Linux System. cmarks: 0.30.3, 0.29.0, 0.28.3, 0.27.1, 0.26.1, 0.25.2, 0.24.1, 0.20.0, apt-get, Homebrew. All tests pass on Linux and macOS, though the latter requires an updated version of ExtUtils::MakeMaker that includes Perl-Toolchain-Gang/ExtUtils-MakeMaker#402 so that it always finds cmark at runtime the same place it found it at compile time. Windows tests do not currently pass at all: 5.32 compiles but then `make test` cannot find the cmark DLL; 5.38 doesn't get past `perl Makefile.PL`, saying it cannot find the cmark library, even though INC ane LIBS are set. Also: update `.gitignore` to ignore additional files, and to specify root-level files and directories.
Create a GitHub workflow to test CommonMark against all supported versions of Perl and cmark on Linux, macOS, and Windows. Include tests for the system default Perl and and package-supplied cmark on Linux (Apt) and macOS (Homewbrew), as well. Each version of cmark has two steps: one for macOS and Linux using `build.sh`, and one for Windows using `build.ps1`. Just add new steps to test new versions. Perls: 5.38, 5.36, 5.34, 5.32, 5.30, 5.28, 5.26, 5.24, 5.22, 5.20, 5.18, 5.16, 5.14, 5.12, 5.10, 5.8, macOS system, Linux System. cmarks: 0.30.3, 0.29.0, 0.28.3, 0.27.1, 0.26.1, 0.25.2, 0.24.1, 0.20.0, apt-get, Homebrew. All tests pass on Linux and macOS, though the latter requires an updated version of ExtUtils::MakeMaker that includes Perl-Toolchain-Gang/ExtUtils-MakeMaker#402 so that it always finds cmark at runtime the same place it found it at compile time. Windows tests do not currently pass at all: 5.32 compiles but then `CommonMark->parse_file` dies without any error output in `t/02_accessors.t` and `t/10_wrappers.t` (I thought the issue might be the path, but use of File::Spec does not fix it). 5.38 doesn't get past `perl Makefile.PL`, saying it cannot find the cmark library, even though INC and LIBS are set. Also: update `.gitignore` to ignore additional files, and to specify root-level files and directories, and add some diagnostic output to `t/01_memory.t` to show the versions of cmark.
Create a GitHub workflow to test CommonMark against all supported versions of Perl and cmark on Linux, macOS, and Windows. Include tests for the system default Perl and and package-supplied cmark on Linux (Apt) and macOS (Homewbrew), as well. Each version of cmark has two steps: one for macOS and Linux using `build.sh`, and one for Windows using `build.ps1`. Just add new steps to test new versions. Perls: 5.38, 5.36, 5.34, 5.32, 5.30, 5.28, 5.26, 5.24, 5.22, 5.20, 5.18, 5.16, 5.14, 5.12, 5.10, 5.8, macOS system, Linux System. cmarks: 0.30.3, 0.29.0, 0.28.3, 0.27.1, 0.26.1, 0.25.2, 0.24.1, 0.20.0, apt-get, Homebrew. All tests pass on Linux and macOS, though the latter requires an updated version of ExtUtils::MakeMaker that includes Perl-Toolchain-Gang/ExtUtils-MakeMaker#402 so that it always finds cmark at runtime the same place it found it at compile time. Windows tests do not currently pass at all: 5.32 compiles but then `CommonMark->parse_file` dies without any error output in `t/02_accessors.t` and `t/10_wrappers.t` (I thought the issue might be the path, but use of File::Spec does not fix it). 5.38 doesn't get past `perl Makefile.PL`, saying it cannot find the cmark library, even though INC and LIBS are set. Also: update `.gitignore` to ignore additional files, and to specify root-level files and directories, and add some diagnostic output to `t/01_memory.t` to show the versions of cmark.
Create a GitHub workflow to test CommonMark against all supported versions of Perl and cmark on Linux, macOS, and Windows. Include tests for the system default Perl and and package-supplied cmark on Linux (Apt) and macOS (Homewbrew), as well. Each version of cmark has two steps: one for macOS and Linux using `build.sh`, and one for Windows using `build.ps1`. Just add new steps to test new versions. Perls: 5.38, 5.36, 5.34, 5.32, 5.30, 5.28, 5.26, 5.24, 5.22, 5.20, 5.18, 5.16, 5.14, 5.12, 5.10, 5.8, macOS system, Linux System. cmarks: 0.30.3, 0.29.0, 0.28.3, 0.27.1, 0.26.1, 0.25.2, 0.24.1, 0.20.0, apt-get, Homebrew. All tests pass on Linux and macOS, though the latter requires an updated version of ExtUtils::MakeMaker that includes Perl-Toolchain-Gang/ExtUtils-MakeMaker#402 so that it always finds cmark at runtime the same place it found it at compile time. Windows tests do not currently pass at all: 5.32 compiles but then `CommonMark->parse_file` dies without any error output in `t/02_accessors.t` and `t/10_wrappers.t` (I thought the issue might be the path, but use of File::Spec does not fix it). 5.38 doesn't get past `perl Makefile.PL`, saying it cannot find the cmark library, even though INC and LIBS are set. Also: update `.gitignore` to ignore additional files, and to specify root-level files and directories, and add some diagnostic output to `t/01_memory.t` to show the versions of cmark.
Create a GitHub workflow to test CommonMark against all supported versions of Perl and cmark on Linux, macOS, and Windows. Include tests for the system default Perl and and package-supplied cmark on Linux (Apt) and macOS (Homewbrew), as well. Each version of cmark has two steps: one for macOS and Linux using `build.sh`, and one for Windows using `build.ps1`. Just add new steps to test new versions. Perls: 5.38, 5.36, 5.34, 5.32, 5.30, 5.28, 5.26, 5.24, 5.22, 5.20, 5.18, 5.16, 5.14, 5.12, 5.10, 5.8, macOS system, Linux System. cmarks: 0.30.3, 0.29.0, 0.28.3, 0.27.1, 0.26.1, 0.25.2, 0.24.1, 0.20.0, apt-get, Homebrew. All tests pass on Linux and macOS, though the latter requires an updated version of ExtUtils::MakeMaker that includes Perl-Toolchain-Gang/ExtUtils-MakeMaker#402 so that it always finds cmark at runtime the same place it found it at compile time. Windows tests do not currently pass at all: 5.32 compiles but then `CommonMark->parse_file` dies without any error output in `t/02_accessors.t` and `t/10_wrappers.t` (I thought the issue might be the path, but use of File::Spec does not fix it). 5.38 doesn't get past `perl Makefile.PL`, saying it cannot find the cmark library, even though INC and LIBS are set. Also: update `.gitignore` to ignore additional files, and to specify root-level files and directories, and add some diagnostic output to `t/01_memory.t` to show the versions of cmark.
Introduction
I did some research to try to better understand the way shared libraries are generated and used on macOS. I include it here as an introduction. See below for the actual issue with
ExtUtils::MakeMaker
On Linux it is enough to set the environment variable
LC_RUN_PATH
when compiling a shared library. This will make the linker include the run path given in theLC_RUN_PATH
variable into the shared library. On macOS it is more complicated. Each library has a header providing an install name (LC_ID_DYLIB
) of the library. If other libraries should be able to find this library through their own run time path (rpath) the install name of the current library must begin with the special string@rpath
. Secondly, if this library is trying to load another library using its rpath the header section of this library calledLC_LOAD_DYLIB
must include the rpath install name of the other library. This means that the name in theLC_LOAD_DYLIB
section must start with the special string@rpath
. Thirdly, this library must include anLC_RPATH
section with the run time paths to the libraries (the ones whose names starts with@rpath
) given in theLC_LOAD_DYLIB
section.When linking a shared library on macOS (using here
cc
=clang
as the most relevant example),-install_name
can be used to set theLC_ID_DYLIB
section for the generated shared object,-rpath
or-Wl,-rpath,
can be used to set theLC_RPATH
section,LD_RUN_PATH
can be used to set the@rpath
prefix of library names in theLC_LOAD_DYLIB
sectionSee this link for more information.
Here is an example: I have the following files on my mac (Big Sur 11.5.2) :
and the file contents are:
Let's say I compile the libraries like this:
we can then note :
-install_name
with the@rpath
prefix when compiling bothlibmylib1.dylib
andlibmylib2.dylib
. Forlibmylib1.dylib
it necessary in order for the dynamic linker (when loading the main program, which then loadslibmylib2.dylib
) to acceptlibmylib1.dylib
using the rpath included inlibmylib2.dylib
). Forlibmylib2.dylib
it is necessary in order for the dynamic linker to accept it using the rpath in the main program when loading the main program.LD_RUN_PATH
when compilinglibmylib1.dylib
since it is not loading any shared libraries on its own through its rpathLD_RUN_PATH
when compiling both the main program andlibmylib2.dylib
since both are loading a shared object through their rpath.libmylib2.dylib
( I omitted this by purpose to illustrate what happens) such that it cannot findlibmylib1.dylib
If I now try to run the main program:
However, if I recompile
libmylib2.dylib
and add the option-rpath ../mylib1
:and then rerun, it works:
Problem with
ExtUtil::MakeMaker
When compiling an XS module on macOS that refers to another shared library (in a nonstandard location with explicit path given in the
LIBS
argument toWriteMakefile()
), the generated Makefile does not include the-rpath
option tocc
which then fails to set theLC_RPATH
section of the generated.bundle
. This makes it necessary for the user to do some extra work to make the module useable. For example, setting the environmentDYLD_LIBRARY_PATH
, or manually modify the.bundle
afterwards usinginstall_name_tool
, like in this issue.The text was updated successfully, but these errors were encountered: