# Hard coded executable paths

**URL:** https://openziti.discourse.group/t/hard-coded-executable-paths/791
**Category:** Building/Development
**Created:** [October 1, 2022, 12:11am UTC](https://openziti.discourse.group/t/hard-coded-executable-paths/791 "2022-10-01T00:11:50Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![sabedevops](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sabedevops/32/552_2.png) [@sabedevops](https://openziti.discourse.group/u/sabedevops)
#### Post date: [October 4, 2022, 11:42pm UTC](https://openziti.discourse.group/t/hard-coded-executable-paths/791/4 "2022-10-04T23:42:51Z")

</div>

Hey John,

I finally had a chance to review the source code that handles this bit, my apologies for the delay.

After looking over the logical flow, I would’ve expected a release package to work using the `libsystemd` integration in the `ziti-edge-tunnel`. While libsystemd is needed as a build time dependency of this integration, it is the runtime dependency we are concerned with in this case.

If the binary can `dlopen()` libsystemd on your system, then the hard-coded path dependencies have no effect, _except_ with regards to inspecting `/etc/resolv.conf`. After doing a quick test, it seems that `realpath("/etc/resolv.conf", ...)` should canonicalize through multiple levels of symbolic links. Are you seeing something different or perhaps I’m misunderstanding the problem space?

I saw in the [https://openziti.discourse.group/t/static-binary-artifacts-for-ci-releases/790](https://openziti.discourse.group/t/static-binary-artifacts-for-ci-releases/790) thread, that you attempted to solve this by using `patchelf --add-needed`, but I’m wondering if this should’ve been some form of `patchelf --add-rpath ...`? After some googling, maybe the rpath here should be the same as the `-L` path which results from running `nix-shell -p systemd pkg-config --run 'pkg-config --libs libsystemd'`?

What was the error you were seeing after the patches you made in the other post?

With regards to the fallback to the binaries, as written, the easiest path would be to allow them to be overriden at build time. With the code as written, the idea of searching $PATH would have to be carefully implemented. Also, a major hurdle in our case is that we use CMake’s CPack to package the ZET for the other formats, and I couldn’t find a generator for NixOS format.

Thanks,  
- Steven

FYI, the error in dlopen() results in the fallback to hard-coded paths, but does not interrupt application startup. In the case that the hardcoded paths cannot be found, it should still fallback to manipulating `/etc/resolv.conf` directly (though this portion is naive in flawed at this time).

---

_[View the full topic](https://openziti.discourse.group/t/hard-coded-executable-paths/791)._