Repository navigation
Conversation
There was a problem hiding this comment.
can we keep the default symbol visibility hidden? even if due to the symbol tags, we work around the issue for exported symbols, there is no need to export more symbols than before
There was a problem hiding this comment.
The removed code was actually dead code, the parameter list was never passed to the build so the default visibility was used. Changing it to hidden would also break the FIPS functionality where EVP_* symbols are used, or any other extension that is using OpenSSL symbols. I would keep it the way it was before. I also fixed the C flag passing in 7d4c096 as it the parameter name was also wrong there.
| # core-minifi exports the symbols of its statically linked dependencies (e.g. OpenSSL), which extensions rely on. | ||
| # Tagging them with a minifi specific version prevents libraries loaded later (e.g. python's _hashlib referencing | ||
| # EVP_*@OPENSSL_3.0.0) from binding to these copies instead of their own dependencies (e.g. the system libcrypto). |
There was a problem hiding this comment.
I'd move this comment to core-minifi.map
| if (UNIX AND (CMAKE_SYSTEM_PROCESSOR MATCHES "armv7")) | ||
| target_link_libraries(core-minifi "-latomic") | ||
| endif() | ||
| if (CMAKE_SYSTEM_NAME STREQUAL "Linux") |
There was a problem hiding this comment.
Is this still an issue on windows and macos?
There was a problem hiding this comment.
It should be specific to Linux, but I could not test or reproduce it on Windows or Mac.
Reproduced the symbol clashing issue issue with older OpenSSL 3.3.6 built from source. Statically linking that to MiNiFi resulted in the crash on Ubunutu 26.04 with system installed OpenSSL version 3.5.5. This change mitigates the issue, removing the interference with the system OpenSSL library by tagging the exported symbols with MINIFI_CORE.
https://issues.apache.org/jira/browse/MINIFICPP-2743
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically main)?
Is your initial contribution a single, squashed commit?
For code changes:
For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.