Developer installs and runs C++ executable with shared library dependencies
- Dominant language
- No language data
- Stars
- 94
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Description
@adammurdoch commented on [Mon May 22 2017](https://github.com/gradle/stable-native/issues/23)
Split out of #2. Ensure that executables are linked such that absolute paths to libraries are not baked into the executable. This will allow the libraries to be relocated via a binary repository or the build cache. However, doing this will mean that an executable with shared library dependencies will not be usable until the dependencies are visible to the executable in some way at runtime.
This story adds some convenience for a developer to install or stage either the executable or the libraries that it uses or both so that the developer can run and debug an executable.
Investigate options for removing the generated script, e.g. copy the libs into the same directory as the executable, and also tweak the `soname` or `rpath` values baked into the binaries.
Contributor guide
Research direction
Start by investigating how native executables are linked and how the generated runtime script currently exposes shared libraries. Compare options for staging the executable, its libraries, or both, including the effects of soname and rpath values. Done means a developer can install or stage the required artifacts and run and debug the executable without absolute library paths baked into it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100