Yeah, precisely. We're aiming to simultaneously
- maintain compatibility with quite old versions of MATLAB (down to R2009
at the moment),
- where possible, make use of prebuilt libraries from Anaconda, e.g. for
arrow-cpp, boost, gtest etc
Our build infrastructure also doesn't easily support GCC 6.
Hello all,
the conda packages from conda-forge use gcc and libstdc++ 7.3, i.e. are a major
version newer than the ones that come with Matlab. Thus the missing symbols and
the need for LD_PRELOAD. As long as Matlab is using an older version of
gcc/libstdc++, the missing symbols will continue to
Hi Joris,
Nice to hear from you! I'd like the understand the need to use LD_PRELOAD for
picking up a different libstdc++. In case haven't found this already, MATLAB
even vendors a libstdc++ as per:
(pwd = matlabroot)
% more sys/os/glnxa64/README.libstdc++
The GCC runtime libraries included h
Hello Uwe,
Yes, it would appear that was the case. Aggregating yours and Wes'
suggestions, I'm now:
- Compiling arrow-cpp myself, explicitly with the new ABI, and publishing
this on our internal conda channel (as gsa-arrow-cpp, so it can be
explicitly depended upon). Did this by tweaking
https://
Hello Joris,
'/data/home/jpeeter/apps/anaconda3/envs/testarrow/lib/fromArrowStream.mexa64':
/data/home/jpeeter/apps/anaconda3/envs/testarrow/lib/fromArrowStream.mexa64:
undefined symbol: _ZNK5arrow6Status8ToStringEv.
sounds like fromArrowStream.mexa64 was still compiled using
-D_GLIBCXX_USE_CXX
hi Joris,
You probably ran into the conda-forge compiler migration. I'm not sure
about Anaconda's Apache Arrow libraries since they maintain those
recipes.
If you need shared libaries using the gcc 4.x ABI you may have to
build them yourself right, or use the Linux packages for the platform
where
