-
Notifications
You must be signed in to change notification settings - Fork 55
rust - re-export libceed-sys features through libceed to allow building non-static without using libceed-sys directly #1813
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
base: main
Are you sure you want to change the base?
Conversation
…ng non-static without using libceed-sys directly
Thanks for bringing this up again and creating the PR! Out of curiosity: Are you sure that this isn't a necessary change in order to link
will result in
will result in The possible fixes are either:
Happy to hear your thoughts, and if you prefer 2), then I'm happy to implement that instead of the feature re-export. |
I should have written more carefully. I was thinking of having [dependencies]
libceed-sys = { version = "0.12", path = "../libceed-sys", default-features = false} but skipping the re-exporting of features. I think that supports all use cases, but requires transitive naming of |
Ah, thanks for clarifying. I'm personally not a fan of depending on transitive naming and instead in favor of removing the |
Do you mean something other than the existing |
This way no features are activated by default. It has the downside that if only the shared feature is enabled, it will attempt to statically link to the system library (which is most likely a shared library).
Yes, in my mind they serve different purposes: I have to admit that my motivation for a Cargo-built shared libCEED is quite niche. I would like to retain the ability to do this purely because of the weak symbol problem on MacOS when linking statically (#1694), which I have not been able to solve, so I link libCEED dynamically as a bandaid solution. I can absolutely see how thats not a common case though and can see an argument for removing private shared builds to streamline the features. In that case I'll need to separately build/install libCEED while on my MacOS machine instead of having Cargo build it. That would be a little inconvenient but acceptable since that'll be necessary for any device support anyways. |
Okay, I pushed a commit to swap the feature names, but it'll use |
This works for me and I think this is a relatively good solution. What's your concern with it? |
Just that activating |
I see. If you feel that this is a significant factor then I find removing |
Revisiting this while trying to understand the root issue of weak symbols not working with static linking on MacOS. I don't have a solution there, but I found that |
I also faced the |
Fix #1694
I will note that there is nothing wrong with depending on
libceed-sys
directly to set the feature at that level, so I don't think this is a necessary change, just a convenience.Thanks-to: @eliasboegel