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 -----
<[EMAIL PROTECTED]>
(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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
