[
https://issues.apache.org/jira/browse/PARQUET-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216244#comment-15216244
]
Blake Ryan commented on PARQUET-487:
------------------------------------
How will this work with upstream dependencies? When I build thrift and parquet
today, I get the following failure:
/usr/bin/ld: /usr/local/lib/libthrift.a(TProtocol.o): relocation R_X86_64_32S
against `_ZTVN6apache6thrift8protocol16TProtocolFactoryE' can not be used when
making a shared object; recompile with -fPIC
I can work around this by configuring parquet-cpp to build statically.
Do you build thrift with -fPIC?
> Add cmake options for various dependency-linking scenarios
> ----------------------------------------------------------
>
> Key: PARQUET-487
> URL: https://issues.apache.org/jira/browse/PARQUET-487
> Project: Parquet
> Issue Type: Improvement
> Components: parquet-cpp
> Reporter: Wes McKinney
>
> Unless {{libparquet}} is being built as part of a statically-linked
> application toolchain, it may be preferable in a lot of cases to use dynamic
> linking with its dependencies, rather than statically linking everything as
> it does now.
> I envision several distinct use cases we should support
> * {{libparquet.so}}, with no dependencies statically linked that have shared
> libraries available
> * {{libparquet.so}}, with all dependencies statically linked (this is what we
> are doing now)
> * {{libparquet.a}}, with all dependencies statically linked
> * {{libparquet.a}}, without any unnecessary static linking
> Having these options accessible through cmake flags will help users of
> parquet-cpp avoid dependency hell in some cases, and incorporate libparquet
> in the desired way into a 3rd-party build toolchain
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
