-
Notifications
You must be signed in to change notification settings - Fork 14
Openssl #294
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: master
Are you sure you want to change the base?
Openssl #294
Conversation
recipes/libs/openssl.yaml
Outdated
| patchApplySeries $<@openssl/*.patch@> | ||
|
|
||
| Config: | ||
| OPENSSL_ADDITIONAL_OPTIONS: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to name the algorithms explicitly like buildroot does? This catch-all variable seems a bit coarse grained. Even if not done now, would it be a problem on your side if we go in this direction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I can do this.
recipes/libs/openssl.yaml
Outdated
| Config: | ||
| OPENSSL_ADDITIONAL_OPTIONS: | ||
| help: additional configure options | ||
| OPENSSL_LINK_MODE: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea for such things was to set BASEMENT_LIBS to shared when declaring the dependency:
depends:
- name: libs::openssl
environment:
BASEMENT_LIBS: sharedThis will override the heuristic for cpackageLibraryType. Of course, this will apply for the dependencies as well.
Actually, I think our openssl recipe is wrong and should pass no-dso in case of static linking. At least buildroot does that and it looks correct to me. Would you mind fixing that with a separate commit while you're at it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With BASEMENT_LIBS: shared all dependencies are also shared so ATM we need at least to provide the zlib Path when running openssl. Using the OPENSSL_LINK_MODE it's still linked static against zlib, so no need for this. OTOH I could just package zlib with openssl?
Actually, I think our openssl recipe is wrong and should pass no-dso in case of static linking. At least buildroot does that and it looks correct to me. Would you mind fixing that with a separate commit while you're at it?
I'll add it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With
BASEMENT_LIBS: sharedall dependencies are also shared so ATM we need at least to provide thezlibPath when running openssl. Using theOPENSSL_LINK_MODEit's still linked static against zlib, so no need for this. OTOH I could just packagezlibwithopenssl?
My gut feeling is that statically linking zlib with dynamically loaded plugins is calling for trouble. Buildroot even forces "zlib-dynamic" on shared link builds. I wouldn't go so far but compiling zlib shared seems like a good idea. So in the end we could have a "tools" multiPackage that gathers *-tgt and it should work fine in all cases.
Update openssl to latest LTS Release.
Add a special package providing the openssl-tool. This is required since we need to gather all dependencies if the tool is linked shared to support loadable plugins.
No description provided.