Hi Wes,
Here is the shell transcript [1], I ran it with your patch included, and
it's still not resolved.
[1] https://gist.github.com/keithgchapman/b3e9ee2df2d2a3e6d6efde1f2b6c6d89
Regards,
Keith.
http://keith-chapman.com
On Wed, Feb 22, 2017 at 1:14 PM, Wes McKinney
Thanks, this is helpful. The shared library 3rd-party dependencies are
not being properly linked in the executables. It seems (?) it could
depend on the CMake version. For example, on my system (Ubuntu 14.04)
with
$ cmake --version
cmake version 2.8.12.2
with $CC and $CXX set and
cmake ..
Hi Wes,
You can find the shell transcript here [1].
[1] https://gist.github.com/keithgchapman/ee2ce6f27868f532d7c0dfceaae874ed
Regards,
Keith.
http://keith-chapman.com
On Wed, Feb 22, 2017 at 12:14 PM, Keith Chapman
wrote:
> I actually had 2 versions of boost, I
I actually had 2 versions of boost, I built 1.54 once for a different
project (which I do not need anymore), I got rid of it and now it picks up
1.58 but still gives the same error. Will upload a complete shell
transcript.
Regards,
Keith.
http://keith-chapman.com
On Wed, Feb 22, 2017 at 12:04
How did you build Boost? If you could upload a complete shell
transcript starting from a clean git clone (run "git clean -fdx ." in
your clone) to GitHub gist or someplace else I can take a closer look.
Ubuntu 16.04 claims to be shipping Boost 1.58, so you may need to set
a different $BOOST_ROOT
Interestingly if I build with the following (instead of having
-DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_C_COMPILER=gcc-4.9)
export CC="gcc-4.9"
export CXX="g++-4.9"
cmake .. -DCMAKE_BUILD_TYPE=release -DPARQUET_BUILD_TESTS=Off
I get rid of the arrow related linkage errors and end up with only boost
Yes, I get it on a clean build.
Regards,
Keith.
http://keith-chapman.com
On Wed, Feb 22, 2017 at 11:42 AM, Wes McKinney wrote:
> Do you get these errors from a clean build (i.e. you've removed all
> the artifacts and CMake files from your prior build)? We are building
>
Do you get these errors from a clean build (i.e. you've removed all
the artifacts and CMake files from your prior build)? We are building
in Travis CI with gcc/g++ 4.9 and have not been having any issues:
https://github.com/apache/parquet-cpp/blob/master/ci/before_script_travis.sh#L20
On Wed,
Hi Wes,
Tried the patch and it does the trick, thank you for the prompt response.
Also I noticed another issue, not sure if you'd regard it as a bug or not
but I'll throw it out for your consideration. If I build the parquet
library with
"cmake . -DCMAKE_BUILD_TYPE=release
You can try out this patch if you like:
https://github.com/apache/parquet-cpp/pull/258
This should be included in the next 1.0.0 RC
On Wed, Feb 22, 2017 at 1:32 PM, Keith Chapman wrote:
> Thanks Wes.
>
> Regards,
> Keith.
>
> http://keith-chapman.com
>
> On Wed, Feb
Thanks Wes.
Regards,
Keith.
http://keith-chapman.com
On Wed, Feb 22, 2017 at 10:30 AM, Wes McKinney wrote:
> I'm able to reproduce the issue on Ubuntu 14.04
>
> Linking CXX shared library debug/libparquet.so
> /usr/bin/ld: /usr/lib/libsnappy.a(snappy.o): relocation
I'm able to reproduce the issue on Ubuntu 14.04
Linking CXX shared library debug/libparquet.so
/usr/bin/ld: /usr/lib/libsnappy.a(snappy.o): relocation R_X86_64_32S
against `.rodata' can not be used when making a shared object;
recompile with -fPIC
/usr/lib/libsnappy.a: error adding symbols: Bad
Hi Wes,
No I don't have SNAPPY_HOME set. Yes this seems similar to 885
On Feb 22, 2017 10:25 AM, "Wes McKinney" wrote:
> hi Keith,
>
> It's not caused by PARQUET-885, but it is the same type of problem. Do
> you have $SNAPPY_HOME set? If you compile your own thirdparty
>
Hi,
I'm trying to build master and I get the following error, I have the .so
versions of the files as seen below too, Is this somewhat relaped to
Parquet-885?
ls /usr/lib/x86_64-linux-gnu/libsnappy.
libsnappy.a libsnappy.solibsnappy.so.1
libsnappy.so.1.3.0
Error seen:
14 matches
Mail list logo