-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
Use dlopen, dlsym, etc. to minimize depnendencies #349
Comments
8 years ago libcurl used dlopen() to load LDAP libraries. It did not work well in certain scenarios, so the code was changed not to use dlopen(). See d0edb47. |
Appears libcurl was "manually" dynamically linking the LDAP libraries using In libextractor, there are modules for each filetype that live under It's therefore As an aside, there is a |
I think this is a pretty interesting idea. I would say that a primary obstacle would be that it would need to be configurable since we have lots of users who want everything build statically and libcurl builds and runs on many systems that don't load stuff at run-time like normal *nix systems. This is not a priority feature for me personally so I'm not likely to work on it anytime soon. I'd be willing to help out if anyone else is willing to experiment. |
I understand |
I'm sure there are several possible ways to implement it, I'm just saying it needs to be taken into account when/if someone decides to work on this. |
It's worth mentioning that libextractor has a bunch of similar design consideraints to libcurl, both dynamically link against many external libraries, most of which are rarely used, both run on many platforms, etc. But
libextractor.so
andextract
are linked directly against relatively few external dependencies.Instead of directly linking to libraries it only rarely uses, libextractor builds a shared object plugin for the different filetypes it supports, and those shared objects link against the external libraries they need. See : https://www.gnu.org/software/libextractor/
I'd imagine doing this with libcurl would be an unpleasently large change, but if done well it'd buy libcurl users some additional flexibility. At minimum, it'd simplify packaging libcurl for distributions that usually do not want stuff like LDAP, SSH, etc. but cannot exclude them all outright. And importantly plugins would aid in tightening AppArmor and SELinux profiles for applicaitons that use libcurl. It might therefore be worth considering such a change for "some future version".
The text was updated successfully, but these errors were encountered: