Sorry, I think I wasn't clear. I mean the broader issue of C++ extension code. In
principle it should be possible to mix C++ extension modules in the same Python process,
at least in some cases, especially if they link their own dependencies statically. While
"just do it our way, use our
> However, extension modules are always going to have to share the Python
> process, so this policy kind of says, you can't use external C++ extension
> code with conda.
This is a bit too extreme. What I meant is that you should try not to
mix C++ build toolchains. I think this is good advice
It sounds like for your use case that it would be better for you to
build your own Arrow packages that use the same Boost as the rest of
your repo. You can possible use the scourge tool that Phillip built to
help with this (we're using it to build nightlies).
conda-forge is a fairly closed
OK, though if both modules linked Boost statically, I believe they would have
distinct copies of global variables. Whether or not this causes problems
depends on whether they are purely internal or tied to external state. My
hunch is that for Boost::regex, there wouldn't be an issue with two
Static linking does not really solve all problems in the Boost case as there
are global variables that are picked up across different Boost versions. Thus
if you link it statically it still has an effect on other dependencies. In the
case of boost, you can get around this by using the bcp tool
Hi,
The issue is here no that Boost is linked statically in one and dynamically in
another but that you link against two different boost versions. The stacktrace
shows links to Boost 1.55 whereas Arrow should be linked against 1.65 or 1.66
(the one coming from conda-forge). Arrow requires at
Hi there,
Sure, I'll append top of the stack. You can see our internal function
"asd::infra::util::start_of_date"; everything else is Boost, Python, or
libstdc++.
My understanding (though I haven't demonstrated this conclusively) is that, because
Python loads extension modules RTLD_GLOBAL,
Hello,
I am not sure why we are linking statically in the conda-forge packages, as a
gut feeling we should link dynamically there. Wes, can you remember why?
Alex, would it be possible for you to send us the part of the segmentation
fault that is not private to your modules. That would be a
