[
https://issues.apache.org/jira/browse/DRILL-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099160#comment-17099160
]
Laurent Goujon commented on DRILL-7714:
---------------------------------------
I guess the issue is twofold:
- drillClient library is opened by a program which has a different libssl loaded
- there is some incompatibility between the openssl version so code compiled
with version X cannot use version Y of the library?
I guess it doesn't have to be a static library vs linking statically openssl to
the dynamic library and making sure symbols are hidden so that there's no
conflict?
As for the patch, it looks like a static library is created which also contains
all the objects present in the dynamic libraries the program is linked for. But
I haven't seen this done for other oss projects, and usually static libraries
only contains objects from the project itself. Is there a strong incentive of
doing this vs letting the user of the static library doing it themselves?
> 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)
