Sorry for pinging, I forgot to add: A issue has been opened in upstream's github about this 16 days ago, no reply until now: https://github.com/minrk/wurlitzer/issues/23
Just to see if they have a more python-sided way of handling this. Cheers. Elias. On Wed, Dec 19, 2018 at 11:02 AM Elias M. Mariani <marianiel...@gmail.com> wrote: > > https://github.com/minrk/wurlitzer > https://pypi.org/project/wurlitzer/ > > Capture C-level stdout/stderr pipes in Python via os.dup2. > > This package is required to update devel/spyder/py-spyder-kernels and > devel/spyder/spyder. > > Taking Maintainership. > > ++++++++++++ > A weird patch has to be made in order to make this package to work properly: > The original script calls to the function fflush from libc with a > parameter to stdout or stderr, for that a pointer is needed. > In linux: > c_stdout_p = ctypes.c_void_p.in_dll(libc, 'stdout') > > But OpenBSD doesn't have a defined symbol for 'stdout' in libc, but an > array of FILE structs called __sF, where __sF[1] corresponds to stdout > and __sF[2] to stderr. > > So in order to bring this array to python we need to know the length > of FILE, create an array and then get a pointer for the elements 1 and > 2 of that array. > > The main problem is to get the length of FILE, is 152 bytes in amd64, > and 88 bytes in i386, no idea in other platforms, but given that this > lengths can change, hardcoding this numbers is ugly and bad... > > That's why I added a small C code and a sh script to get the > sizeof(__sF[1]) and passing that value to sed to then patch the python > script. > > Maybe there is a better way of handling the issue, I don't see it... > My only doubt is that libc is used by the package inside the python > script, and if the size of FILE changes, the package should be rebuilt > to refresh the value of the given size. > Should I add libc as a WANTLIB ? > ++++++++++++ > > Cheers. > Elias.
