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

Allow statically linking libclang #1617

Closed
jsgf opened this issue Sep 11, 2019 · 6 comments
Closed

Allow statically linking libclang #1617

jsgf opened this issue Sep 11, 2019 · 6 comments

Comments

@jsgf
Copy link
Contributor

jsgf commented Sep 11, 2019

The bindgen Cargo.toml mentions a "static" feature, but it doesn't seem to connect to anything. Its dependency on clang-sys always sets the "runtime" features, which forces runtime dynamic loading.

I'd like to build bindgen statically linked with libclang, mostly to make deployment easier. It would be nice to be able to pass the "static" feature through to clang-sys rather than always requiring "runtime".

@emilio
Copy link
Contributor

emilio commented Sep 12, 2019

Wow, looks like that feature has survived all the way since d54fe74 (when it did what it claimed!).

I didn't check what broke it, but probably the switch to libclang clang-sys.

@emilio
Copy link
Contributor

emilio commented Sep 12, 2019

So, I think this is fair. Though right now we support runtime checks for a lot of stuff (so if a libclang function is not available, we fall back, and such).

Would it be acceptable to require a new-enough version of libclang? i.e., something like 6.0 or such?

If so, it should be feasible to build this and conditionally compiling the is_loaded checks for example...

@jsgf
Copy link
Contributor Author

jsgf commented Sep 13, 2019

I have a PR in progress.

@emilio
Copy link
Contributor

emilio commented Sep 14, 2019

Sweet! :)

@emilio
Copy link
Contributor

emilio commented Oct 28, 2019

Fixed by #1620 and #1649.

@emilio emilio closed this as completed Oct 28, 2019
@jethrogb
Copy link
Contributor

This is the cause of #2030

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

Successfully merging a pull request may close this issue.

3 participants