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

[Martin Dvh]

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.
No feedback at all. I thought I was doing many people a favor but the total 
lack of response dissapointed me a bit.
So I am glad somebody noticed.
> 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!
>
>
> > It works with the standard win32 binary distributions of python24-win32 
> > python-numeric-win32, swig-win32, wxpython-win32 and python win32api
> > I still needed to build cppunit,fftw and boost myself (I added the built 
> > cppunit and fftw dlls to my binary gnuradio-core, see links at end of mail)
>
>
> FYI, my cppunit windows patch has been accepted by the maintainers, 
> I hope it will show up in the next official release.
> I tried to convince the fftw maintainers about the patch, I'm not
> sure I succeeded in. Besides, their release cycle is pretty long.
>
> 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?
No, not yet. I didn't know what the prefered way was to contribute patches so I 
just sent it to the list.
After I received your mail I tried to subscribe to patch-gnuradio but got the 
following back:
   ----- The following addresses had permanent fatal errors -----
<address@hidden>
    (reason: 550 unknown user)

> I've tested some bits of the patch, and IMHO, various parts need 
> tweaks. For example the LIBGNURADIO_CORE_EXTRA_LDFLAGS is missing in 
> the src/lib/Makefile.am, the new m4 are missing in config/Makefile.am,
Yes, I found out myself that I did write the new macros but forgot to put them 
in the Makefile.am files.

> gr_libgnuradio_core_extra_ldflags.m4 should check the compiler supports
> the option.
Did't know (yet) how to do that.
> To me, the createfilemapping factory should check the second
> mapping is contiguous to the first one, pretty much the same way
> the Cygwin patch to the mmap_tmpfile factory does.
Is this needed?
I did look at the cygwin code but didn't really like the code.
I seems you try to just allocate the memomry and hope it is continuous, if it 
is not try again and again.
In the end, if you stop trying after several attempts this could fail.
While the gnuradio code does not depend on the memory being continuous.
I searched for the places where the mapped memory is used.
I found that all core gnuradio code only uses the first copy.
The only code which uses the second copy is the code which tests the mapped 
memory and this code does not depend on the memory being continuous.
So I thought, why bother.
> 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?
I don't really mind which way the patch is sent.
But I would like to submit the patch myself to see if the patch submitting 
works (since subscribing to patch-gnuradio failed for me)
This will give me some experience in the contribution process.
(I am working on some more nice new features)

If you sent me the modified patch I can also do some regression tests myself
(on, linux and windows).
Could you also make a diff between my original patch and your modified patch.
This way I can learn and it is easier for me to integrate with my latest 
gnuradio code which has a whole load of additional changes.
"Coming soon to a gnuradio near you, gnuradioGPU"
(This is gnuradio on the GPU, on windows and linux. For now just FIR filter and 
some basic blocks, my goal is a complete receiver on the GPU)

> 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.
>
>
> Rem: so far, I only tested the MinGW cross-compilation, no run yet.
>
>
> > I updated the wiki with links to my new files:
> > http://comsec.com/wiki?MinGW
>
>
> Thanks!
>
>
> > 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.
If someone has a macro which can solve this problem then that would be great.
I think it could also be solved by a patch to libtool.
(The problem is that libtool thinks files starting with c:/  are not absolute 
pathnames.
Which is strange because the code in libtools seems to check for this, but 
apparently it doesn't work)
> > ./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 ?
>
>
> > --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
>
>
> Any plan on submitting it to patch-gnuradio at gnu.org ?
Sure, I will sent it in. It is still alpha code, but a good starting point (Now 
there is nothing, so it can't get worse ;-)

> Eric, what's your position on this?
>
>
> > 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.
> >
> >
> > http://comsec.com/wiki?MinGW
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/
> >
> > source, readmes and the patch:
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/readme.mingw
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gnuradio-core-2.5cvsmingw-clean-3.patch
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gnuradio-core-2.5cvsmingw.tar.gz
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gr-audio-windows-0.1.tar.gz
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/source/gr-wxgui-0.3-mingw.tar.gz
> >
> > binary:
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/readme.mingw-bin
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/gnuradio-core-2.5cvsmingw-bin.zip
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/readme.mingw-bin-seperate
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/gnuradio-core-2.5cvsmingw-bin-separate/
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/gr-audio-windows-0.1-binary.zip
> > http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/binary/gr-wxgui-0.3-mingw-built.tar.gz
> >
> > I hope this is of use for anyone.
> > Please post results to the list (or modify the wiki to clarify things)
>
>
> In the end, that'd be great to be able to produce an install wizard 
> (thanks to Inno Setup (http://www.jrsoftware.org/isdl.php) of this binary 
> distribution.  Bundling this distribution with USRP drivers, MinGW/MSYS, etc.
> on a CDROM would make a perfect starter kit for the folks under Windows.
Would be great. I must say that I did't test the binary distribution a lot.
There are absolute pathnames to the dlls in the dlls which are different from the paths where I advice to copy them. (I have fftw on a not so logic location on 
my setup)
But windows doesn't seem to bother as long as it can find the dll on its path.

> Cheers