[
https://issues.apache.org/jira/browse/DRILL-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114937#comment-17114937
]
Sanel Zukan commented on DRILL-7714:
------------------------------------
I'm wondering, how this happens? Usually when boost is built, it is linked with
matching openssl version.
What system you running?
> Build DrillClient as a static archive
> -------------------------------------
>
> Key: DRILL-7714
> URL: https://issues.apache.org/jira/browse/DRILL-7714
> Project: Apache Drill
> Issue Type: New Feature
> Affects Versions: 1.17.0
> Reporter: Sidharth Jha
> Priority: Major
> Attachments: 00177131.zip, stacktraces.txt
>
>
> Hi,
>
> We encountered an issue recently which results due to the fact that the
> application loads a different version of an openssl symbol (SSL_CTX_NEW from
> 1.0.0) than what the boost archive (used by drill client) was being built
> with (i.e., SSL_CTX_NEW 1.1.1). Attaching a sample stack trace, and my
> standalone reproducer. Now there are two ways to fix this.
> # Use a custom versioning script, and pass it to the linker to only put the
> symbols in the .global section which need to be imported by other libraries
> using drillClient. Needless to say, this would make sure that symbols such as
> SSL_CTX_NEW doesn't show up in .dynsym, and cause issues with the runtime
> loader.
> # Build drill client as an archive to allow static linking to any
> application, so that it can use a versioning script similar to what's
> mentioned in the previous point to ensure that this ambiguity does not occur.
> The latter is easier to maintain, from DrillClient's perspective.
> Further details are in the attached archive. Please refer to the readmes
> within.
>
> Thanks & Regards,
> Sid
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
