Skip to content
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

Dynamically Linking Dependencies #254

Open
ghost opened this issue May 28, 2017 · 4 comments
Open

Dynamically Linking Dependencies #254

ghost opened this issue May 28, 2017 · 4 comments

Comments

@ghost
Copy link

ghost commented May 28, 2017

I am interested in creating a habitat package for statsite. Very similar to how other package managers emphasize dynamically linking dependencies vs statically linking dependencies, would it be possible to introduce an option to dynamically link to the dependencies that are currently statically linked against from the deps folder?

@johnkeates
Copy link
Contributor

It could be done but has no real benefit. The dependencies aren't really available in any distro and are (so far) not re-used anywhere. Statsite has no real dependencies for the normal runtime version, and the deps dir is more to sort out internal sources vs. external sources than actually copy/pasting complete libraries. I believe it's not changed once since the statsite project was started.

Dynamic linking would be possible by removing the ldadd line and re-running autogen, but I'm not sure how configure would find the dependencies elsewhere on the system. I've checked that path out a while back when adding debian packaging support but there was no real library that could be used to replace any of the deps.

If you can find existing libraries for runtime that replace the current deps, that would be great of course.

Regarding check, we include it for convenience and it's not needed at runtime. It's also to make it easier for automated testing to have a specific check version. Using the one available with Debian I could also run the test_runner but it's a lot of hassle for no real benefit to modify it for everyone.

Let me know what your dependency situation looks like, maybe it's available in your setup and we can check possible scenarios for automatic dynamic linking.

@ghost
Copy link
Author

ghost commented May 28, 2017

Thanks @johnkeates. My use case is for Habitat: https://bldr.habitat.sh/#/pkgs/core. In some cases, it is its own package manager by which I am currently tinkering around with creating a Habitat package for statsite. What I can do is attempt to create the dependencies as packages in that eco-system and play around with dynamically linking them using your suggestions.

I may have to come back and ask questions as it's been quite a white since I have played with the c eco-system and may need some guidance to steer me in the right direction :)

@ghost
Copy link
Author

ghost commented May 29, 2017

what is the upstream you are using for murmurhash3.c? I am finding a few sources of this and just wanted to build the right upstream dependency?

@johnkeates
Copy link
Contributor

As far as I know, no known identified upstream of any of the libraries is used. Some of them are available elsewhere, but I don't know which version the original author selected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant