python - Can't redirect error stream from Cython -

the sfml library i'm trying cythonize defines function below allows change errors printed (by default sfml writes error messages console when function not called):

namespace sf {     std::ostream& err() {         static defaulterrstreambuf buffer;         static std::ostream stream(&buffer);         return stream;     } } 

my simplified .pxd file above function:

cdef extern 'sfml/system.hpp' namespace 'sf':     ostream& cerr 'sf::err' () 

and .pyx module, compiles , runs fine, doesn't redirect error messages (they still printed console).

cdef void set_error_handler():     cerr().rdbuf(null)  # call should prevent errors appearing in console silently fails  set_error_handler() 

i'm using msvc , linking statically c++ code.

edit

below example how sfml library logs errors in own code (full source):

... // error, failed load image err() << "failed load image \"" << filename << "\". reason: " << stbi_failure_reason() << std::endl; ... 

my goal suppress error messages 1 above appearing in console , later redirect them own buffer.

there 2 ingredients problem , both in setup-file.

the first ingredient have 2 extensions:

ext_modules = [     extension('nebula.sfml.system', ['nebula/sfml/system.pyx'],               language='c++', ...),     extension('nebula.sfml.graphics', ['nebula/sfml/graphics.pyx'],               language='c++', ...), ]  

that means cython create 2 different shared libraries: system.dll , graphics.dll both loaded later on dynamically python.

the second ingredient: sfml-library linked statically contains singleton (the error-stream in question) , recipe disaster: set-up no longer singleton, there 2 different error-streams: 1 system.dll , 1 graphics.dll. silencing error-stream system.dll (because call set_error_handler() lives there), write error-stream graphics.dll (this image_load_test lives).

so can done? there 2 options:

1. use shared sfml-libraries (at least sfml-system-s), singleton stay singleton.
2. put content of both pyx-files in same pyx-file/extension/shared library. @ least right now, content of system.pyx needed graphics.pyx.