# Building with MSVC v16 **URL:** \ **Category:** GNU Radio\ **Created:** [October 2, 2014, 6:47pm UTC](https://www.ruby-forum.com/t/building-with-msvc-v16/232327 "2014-10-02T18:47:43Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [October 2, 2014, 6:47pm UTC](https://www.ruby-forum.com/t/building-with-msvc-v16/232327/1 "2014-10-02T18:47:43Z")
Hi list. I’ve managed to build Gr using MingW. Now trying the same using Visual C Express 2010 (cl 16), gives me some troubles. I’m just adding all my points here instead of multiple emails. _) reed-solomon/_.[ch] needs ‘FIXED’ to be defined since my cl doesn’t support variable arrays. What bad could happen with ‘FIXED’ defined? Besides ‘-DFIXED’ clashes enormously with the wingdi.h header. So what about ‘GR\_FIXED\_ARRAYS’ instead? \*) The special C++10 (?) features like ‘not’, ‘and’ and ‘or’ doesn’t work here. Do they really bring anything new to Gr? Ref. gr-blocks/lib/multiply\_matrix\_ff\_impl.cc etc. \*) gr-fcd/lib/hid/hid-libusb.c doesn’t have a “config.h” test. I get tons of errors if it’s not these. I added pthreads-w32 to make it work, but I’m not sure it’s a good idea. Are you supporting HID devices on Windows at all? \*) gr-fec/lib/ber\_tools.cc should IMHO have a “config.h” too. \*) In gr-blocks/tests/benchmark\_nco.cc and gr-blocks/tests/benchmark\_vco.cc: ``` #include #include ``` Shouldn’t that be: #include \ #include \ Seems like an oversigth (\*nco.h was once under gr-blocks?) Or could it be trouble at my end? –gv ---
**Author:** ![Gisle\_V](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/b782af/32.png) [@Gisle\_V](https://www.ruby-forum.com/u/Gisle_V)\ **Post date:** [October 6, 2014, 3:51pm UTC](https://www.ruby-forum.com/t/building-with-msvc-v16/232327/2 "2014-10-06T15:51:37Z")
On Thu, Oct 2, 2014 at 12:45 PM, Gisle V. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hi list. > > I’ve managed to build Gr using MingW. Now trying the same > using Visual C Express 2010 (cl 16), gives me some troubles. > I’m just adding all my points here instead of multiple emails. Just to begin with, we do not currently have good support and testing for Windows systems and are actively discussing how to handle this OS. I believe that any support for Windows at all, such as through the current binaries provided by Ettus R., require VS 2012 or something (really not sure, but I believe later than what you’re using). Watch out for a statement soon from us about our Windows efforts and support. Having said that, you bring up some good points. > _) reed-solomon/_.[ch] needs ‘FIXED’ to be defined since my cl > doesn’t support variable arrays. What bad could happen with > ‘FIXED’ defined? Besides ‘-DFIXED’ clashes enormously with the > wingdi.h header. So what about ‘GR\_FIXED\_ARRAYS’ instead? This code has been around forever, and I believe it has built under Windows. I’d rather not change this right now. > \*) The special C++10 (?) features like ‘not’, ‘and’ and ‘or’ doesn’t work > here. Do they really bring anything new to Gr? > Ref. gr-blocks/lib/multiply\_matrix\_ff\_impl.cc etc. No they add nothing and I’m not a fan of them. My guess is that some of it was that code was prototyped in Python and converted over to C++ and these were carried along with it. It’s a hard thing to grep for, but I’ll be patching a few of the cases that I found. > \*) gr-fcd/lib/hid/hid-libusb.c doesn’t have a “config.h” test. I get > tons of errors if it’s not these. I added pthreads-w32 to make it work, > but I’m not sure it’s a good idea. Are you supporting HID devices on > Windows at all? Nope. With our lack of Windows support in general right now, we certainly don’t support this. We will actually be dropping support for gr-fcd in the future, too, since it’s much easier for the hardware manufacturers to handle these issues than us. > \*) gr-fec/lib/ber\_tools.cc should IMHO have a “config.h” too. That code shouldn’t even be there. I meant to remove it when adding FEC API into GNU Radio, but with everything else going on there, this one slipped through. I’ll be removing it since the only thing we used in it was the compber, which is easily replaced by popcount out of VOLK. Nothing was ever exported out of the library, anyways. > Seems like an oversigth (\*nco.h was once under gr-blocks?) Or could it be > trouble at my end? Yes, these were originally in gr-blocks and will be backed. > –gv Thanks! Tom ---
**Author:** ![Gisle\_V](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/b782af/32.png) [@Gisle\_V](https://www.ruby-forum.com/u/Gisle_V)\ **Post date:** [October 7, 2014, 8:39pm UTC](https://www.ruby-forum.com/t/building-with-msvc-v16/232327/3 "2014-10-07T20:39:14Z")
“Tom R.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Just to begin with, we do not currently have good support and testing for > Windows systems and are actively discussing how to handle this OS. I > believe that any support for Windows at all, such as through the current > binaries provided by Ettus R., require VS 2012 or something (really > not sure, but I believe later than what you’re using). I use VS 2010 and Ettus, yes seems to be using VS 2012. I fail to see why VS 2010 isn’t good enough. It was little tweaking to get it to work. > No they add nothing and I’m not a fan of them. My guess is that some of it > was that code was prototyped in Python and converted over to C++ and these > were carried along with it. It’s a hard thing to grep for, but I’ll be > patching a few of the cases that I found. Adding a “#include \” to my specially crafted “config.h” fixed that. GCC includes that unconditionally (thanks to Josh B. for tipping me on that). –gv