Have you looked into using the RHEL "devtoolset"? It allows you to use gcc 4.9 and a newer libstdcxx, and automatically static-links the necessary portions of the library into your application so that it can continue to run on earlier RHEL systems.
This is what we're doing now with Kudu. -Todd On Mon, Mar 7, 2016 at 11:59 AM, Aliaksei Sandryhaila <[email protected]> wrote: > Wes, > > We do have customers that use older Linux versions and use Vertica > compiled without c++11. Since we would like to integrate parquet-cpp into > our product, we need to deal with the c++11 dependency. > > We can maintain this as a separate branch, if you and others don't feel > it's worthwhile incorporating this functionality into the master. > > Thank you, > Aliaksei. > > > > On 03/07/2016 12:02 PM, Wes McKinney wrote: > >> hello, >> >> responses inline >> >> On Mon, Mar 7, 2016 at 8:22 AM, Aliaksei Sandryhaila >> <[email protected]> wrote: >> >>> Hi Wes and Julien, >>> >>> At this point, parquet-cpp is heavily reliant on C++11 features and >>> semantics. Believe it or not :), there are plenty of companies still >>> running older versions of Linux that do not support C++11. Removing this >>> dependency will make parquet-cpp usable (and much more appealing) to >>> them. >>> >>> Just to be clear -- is this a problem for you specifically? Any other >> context would be helpful. >> >> It is not especially difficult to set up a portable C++11 build >> toolchain even on Linux distributions that do not have a new enough >> gcc in their package repository. Both Impala and Kudu have recently >> developed isolated 3rd-party toolchains to facilitate development and >> packaging for these systems. See for example >> https://github.com/cloudera/native-toolchain >> >> We would like to make parquet-cpp C++09 compatible. The end goal is to >>> have >>> a library that can compile with and without --std==c++11 flag. There are >>> two >>> parts of this process. The first one is to redefine or remove C++11 >>> keywords, such as auto, unique_ptr, std::move, or for( : ) loops. The >>> other >>> part is to evaluate our use of C++11 features that are harder to replace, >>> such as shared_ptr, make_shared(), etc., and either write our own >>> implementation for this or modify code where appropriate (such as replace >>> shared_ptr with unique_ptr where possible). >>> >>> We can do this either by maintaining a separate feature branch and >>> periodically pulling new code from parquet-cpp; or by implementing the >>> compatibility functionality directly in parquet-cpp (all future PRs will >>> be >>> tested for c++09 compatibility during CI builds). >>> >>> I'm fairly negative on dropping C++11 in trunk / main library >> development -- it would be a hardship for me personally, and >> additionally deter software engineers who are increasingly coming back >> to C++ development because of C++11/14. >> >> This leaves legacy C++<11 projects that wish to use parquet-cpp as a >> 3rd-party dependency somewhat out in the cold. One approach is to >> provide a wrapper API for projects that cannot interact with APIs that >> use C++11 facilities (like std::unique_ptr). The same approach could >> be used to provide a C API for the project. A wrapper API would be >> much easier to maintain and test without having a separate branch to >> keep in sync -- there might be some pitfalls here that I'm not aware >> of so let me know what you think. >> >> Thanks, >> Wes >> >> What are your thoughts on this? >>> >>> Thank you, >>> Aliaksei. >>> >>> > -- Todd Lipcon Software Engineer, Cloudera
