Skip to content

Conversation

@rhubert
Copy link
Contributor

@rhubert rhubert commented Jan 21, 2026

No description provided.

@rhubert rhubert marked this pull request as draft January 21, 2026 13:55
@rhubert rhubert marked this pull request as ready for review January 23, 2026 13:41
patchApplySeries $<@openssl/*.patch@>

Config:
OPENSSL_ADDITIONAL_OPTIONS:
Copy link
Member

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?

Copy link
Contributor Author

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.

Config:
OPENSSL_ADDITIONAL_OPTIONS:
help: additional configure options
OPENSSL_LINK_MODE:
Copy link
Member

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: shared

This 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?

Copy link
Contributor Author

@rhubert rhubert Jan 26, 2026

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

Copy link
Member

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?

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants