Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui

[Eric Blossom]

On Tue, Jun 28, 2005 at 11:54:32PM +0200, Stephane Fillod wrote:
> Hi Martin,
> 
> Sorry for replying late on your exciting mail.
> Did you get other feedback privately about it or about the Windows port?
> I haven't seen much on my side.
> 
> On Fri, May 20, 2005 at 12:18:55AM +0200, Martin Dvh wrote:
> > I made gnuradio compile on windows using mingw (no cygwin needed)
> 
> No Cygwin? Good!
> 
> Now when boost will recognize gcc-4.x ?
> 
> > I implemented a new gr_vmcircbuf_createfilemapping factory
> > I added O_BINARY flags to all file-operations
> > I hacked the m4 macros
> > I added a sed script (in Makefile.am) to replace all backslashes with 
> > forward slashes in src/lib/swig/gnuradio_swig_python.d
> > Some more hacking.
> > My patched version should still build ok on other platforms but this needs 
> > to be tested.
> > 
> > For source, binary,readmes and the patch:
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gnuradio-core-2.5cvsmingw-clean-3.patch
> 
> Have you already submitted your patch to patch-gnuradio at gnu.org ?
> Do you have any plan about it?

Great work Martin!

> I have fixes in my tree for all the listed issues, and I can check
> regression for Linux. Do you want me to submit them with you as credit,
> or do you prefer that I send them directly to you?

> That would be great to get all this stuff in the GNU Radio 2.6 release,
> so it gets a better chance to be more widely tested.

I'd love to get this stuff in for 2.6, say by sometime next week.
Stephane, can you check these patches for regression against the Linux
x86 build?

Martin, we'll need a copyright assignment to FSF to pick up the bulk
of the patch.  I'll send more info off-list in a bit.

In the bigger picture, we need to revisit the strategy for
searching for libpython.  This is currently breaking the build on
x86-64 and OS/X.   My biggest complaint is that we have introduced a
mostly-unneeded dependency that has made our build environment
brittle. 

Stephane, what I like to see is that the check for libpython and the
corresponding -no-undefined flag only happen on platforms that are
building windows DLLs.

[Additional background: on OS/X libpython has some crazy name and
location.  On x86-64 (SuSE 9.3) libpython is in
/usr/lib64/libpython.so.x.y.z.  The current scheme doesn't find it,
but then goes ahead and drops a -L/usr/lib into the link command line
which breaks everything.  I don't want to continue with the existing
kludge.  These platforms would build fine if we left them alone.]

> > You still need to give a whole lot of options (pathnames) to configure to 
> > work around backslash forward slash problems and libtool absolute pathname 
> > problems.
> > Configure will find python if its on your path but then it uses c:/Python24 
> > as prefix. It just doesn't work if something starts with c:\\somepath or 
> > c:/somepath, it needs to be /c/somepath so you have to override at the 
> > configure commandline.
> > 
> > ./configure  --enable-shared --disable-static --with-md-cpu=generic 
>                                                 ^^^^^^^^^^^^^^^^^^^^^
> I've managed once to have the SIMD speedup working under Cygwin.
> To get them into the CVS, I would need to rename all the files with
> the .s (lowercase) extension to .S (uppercase). This way, I could use
> the preprocessor to morph the .type statements to the appropriate
> forms under Windows. Eric, would that be okay with you to delete/add
> the .s/.S files ?

Is there another way to make this work?  OS/X is case preserving but
case-insensitive.  I think OS/X users will be screwed by this
change -- basically they won't see it.

> > --with-cppunit-prefix=/mingw/cppunit 
> > --with-boost-include-dir=/d/boost_1_32_0/include/boost-1_32 
> > PKG_CONFIG_PATH=/mingw/fftw/lib/pkgconfig PYTHON=/d/Python24/python 
> > am_cv_python_pythondir=/d/Python24/Lib/site-packages 
> > am_cv_python_pyexecdir=/d/Python24/Lib/site-packages 2>&1 | tee 
> > configure.log
> 
> Having them in the wiki and a README allow easy copy/paste 8-)
> 
> > I also implemented a gr-audio-windows  audio-sink (audio-source to be done, 
> > is now an empty stub)
> > This needs some work (synchronisation, it crackles)
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gr-audio-windows-0.1.tar.gz

Good.

> Any plan on submitting it to patch-gnuradio at gnu.org ?
> Eric, what's your position on this?

Love to have it all.

> > I also implemented a hacked gr-wxgui fftsink and scopesink which works with 
> > standard wxpython for windows.
> > (also needs python win32api)
> > This uses win32 named pipes in stead of anonymous os.pipe() because the cpp 
> > code doesn't understand the filedescriptor python gives when using 
> > os.pipe() (It says bad filedescriptor)
> > This works ok for fftsink but the scopesink needs win32 named pipe support 
> > in the gnuradio-core code (or a solution to the filedescriptor problem). I 
> > worked around this by using a standard file-sink in stead of scopesink. 
> > This means no triggers or whatsoever.

Having one way to handle this on all platforms would be good.  Perhaps
we should just use (SysV?) shared memory and a condition variable?  We
could encapsulate the python side in a SWIG-wrapped function that did
the right thing (blocking read from shared memory), and used the
omni_thread stuff to implement.  We'd need a C++ sink that did a
{non-,}blocking write to shared memory.  Comments?

On the other hand, maybe just adding a win32 named pipe sink to C++
and then checking at runtime would be the path of least resistance.
[Do I have this correct?  It take a different system call than "open"
to open a win32 named pipe?]

Eric