[
https://issues.apache.org/jira/browse/DRILL-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sidharth Jha updated DRILL-7714:
--------------------------------
Description:
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
was:
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.
# Allow static linking of drill client to the application, so that it can use
an exports man similar to the one above 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
> 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)
