Conversation
recipes/libs/openssl.yaml
Outdated
| patchApplySeries $<@openssl/*.patch@> | ||
|
|
||
| Config: | ||
| OPENSSL_ADDITIONAL_OPTIONS: |
There was a problem hiding this comment.
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?
recipes/libs/openssl.yaml
Outdated
| Config: | ||
| OPENSSL_ADDITIONAL_OPTIONS: | ||
| help: additional configure options | ||
| OPENSSL_LINK_MODE: |
There was a problem hiding this comment.
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.
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.
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.
|
Thanks! |
2 participants
No description provided.